# Multiple GridFunction.Set() calls

• trh
• New Member
1 year 4 months ago #4687 by trh
Hi,
I'm working with the Helmholtz equation without sources in 3D and using multiple Dirichlet boundary conditions on multiple surfaces. I had been using multiple GridFunction.Set() calls to set these boundary conditions, but just realized that each one overwrites the previous call. Do I really have to find a way to set all boundaries with a single Set() call?

As an example, one Set() call looks like this:
gfu.Set(-V_source, definedon=mesh.Boundaries("source_low"))
With this method of addressing boundaries, I don't immediately see a generalizable way to set multiple boundaries with different values/functions at once. Is there a way to do this in the current API?
Thanks,
Tyler

1 year 4 months ago #4688 by schruste
Hi Tyler,

You can define a domain-wise (or boundary-region-wise in your case) CoefficientFunction that allows you to conveniently set different values on different boundaries. Please take a look at the explanations here: docu.ngsolve.org/latest/i-tutorials/unit...exercises-to-try-out

Best,
Christoph
• trh
• New Member
1 year 4 months ago #4690 by trh
Hi Christoph,
Thanks, this works. But it's not obvious to me why it works. I see in the example that values_list has elements associated with elements in mesh.GetBoundaries() by construction. This ordering is preserved when values_list is used to create a CoefficientFunction? So the definedon= argument causes Set() to attempt to broadcast elements in CoefficientFunction onto mesh elements passed to definedon? And this works if CoefficientFunction has one element or a number of elements equal to the mesh elements passed to definedon?
Tyler
• trh
• New Member
1 year 4 months ago #4691 by trh
Another clarifying question: is there any way to use a similar syntax to set boundaries and the interior of a region? Can you do something like this?
definedon=mesh.Boundaries("some|boundaries")+mesh.Materials("some|materials")
1 year 4 months ago #4693 by schruste
Hi Tyler,

The concept is that the definedon-flags defines where the integration (for the Oswald-type projection) takes place whereas the list in the domain-wise CF-function merely defines how a CF should evaluate on a given integration point. If the integration point is on a boundary the index of the current boundary part dictates which entry in the list is evaluated and if the integration point is in the volume the index of the current material part dictates which entry in the list is evaluated.

A CF is a domain/boundary-wise CF if it is constructed with a list. If you just provide a constant or another (composition of) non-domain-wise CF to the constructor the boundary/material index will not be used so that the CF evaluates as the corresponding expression on all material/boundary parts.

The definedon = ... + ... will not work (as expected) and is not implemented in the way that you expect. Note that there would be dofs that could be defined on both, etc...

Best,
Christoph
Time to create page: 0.121 seconds