dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #19790
Re: [Question #127166]: computing funtionals and settinga fluxcondition
Question #127166 on DOLFIN changed:
https://answers.launchpad.net/dolfin/+question/127166
Johan Hake proposed the following answer:
On Tuesday September 28 2010 10:54:24 Anders Logg wrote:
> Question #127166 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/127166
>
> Anders Logg proposed the following answer:
>
> On Tue, Sep 28, 2010 at 08:50:53AM -0700, Johan Hake wrote:
> > On Tuesday September 28 2010 05:34:06 Achim Schroll wrote:
> > > New question #127166 on DOLFIN:
> > > https://answers.launchpad.net/dolfin/+question/127166
> > >
> > > Hi!
> > >
> > > Thanks for the new tutorial (aug 2010)!
> > >
> > > Ultimately I need to specify a flux condition on a (small) part of the
> > > boundary as explained in Section 6.3. But, is it true that "it is not
> > > possible to perform integrals over different parts of the ... boundary
> > > using ... the VariationalProblem instance"?
> >
> > This should be possible. Just pass a FacetFunction which marks the
> > different Boundary domains, as the exterior_facet_domains.
> >
> > Can you point me to the tutorial. I think I do not have the latest copy.
>
> It's available from http://www.fenics.org/doc/
>
> > > Background: I am solving the nonlinear DEMOSTRAT model and want to
> > > model sediment inflow through a river bed. Just recently, before the
> > > summer, I updated my code to implement the fully nonlinear system and
> > > to use DOLFINs features like automatic form building and nonlinearity.
> > > I don't want to go back to manual linearization etc...
> > >
> > > Another detail:
> > > Any idea what could be wrong when using the code on page 24 to evaluate
> > > the total flux: n = FacetNormal(mesh)
> > > flux = -dot(grad(u),n)*ds
> > > total_flux = assemble(flux)
> > > A runtime error appears: "Unable to extract mesh from form (no mesh
> > > found)" when executing the last line.
> >
> > This because the dolfin::Form which is used to pass the ufc::form to the
> > assembler only chech the FunctionSpaces of the Test and TrialSpaces for a
> >
> > mesh. So you need to pass this manually by:
> > total_flux = assemble(flux, mesh=mesh)
> >
> > I think it would be convinient to be able to assemble a scalar from a
> > Function. The mesh is contained in the FunctionSpace so it should be
> > possible. I then need to figure out if a GenericFunction is a Function
> > or an Expression. Maybe we can add a has_function_space() method to the
> > GenericFunction interface?
>
> Sounds ok to me.
I forgot that I need to dynamic_cast the GenericFunction to a Function to be
able to access the FunctionSpace. Should we assume that all GenericFunctions
that return true for the has_function_space is a Function, or should we just
try to dynamic_cast what ever GenericFunction we get to a Function, and
whenever it works we ask for the function_space? Is the latter safe?
It looks like we have some related issues withing the check() method of Form,
where code has been outcommented because we are not able to distinguis between
a Function and an Expression.
Johan
>
> --
> Anders
--
You received this question notification because you are a member of
DOLFIN Team, which is an answer contact for DOLFIN.
References