search

SCOREC / core

parallel finite element unstructured meshes
Other
181 stars 63 forks source link

initial condition ambiguity by using SimModeler #176

Open yangf4 opened 6 years ago

yangf4 commented 6 years ago

I have a case with two adjacent models regions. In Simmodeler, I set up different initial conditions for these two regions. I am wondering which IC is taken for the mesh vertices on the face between these two regions?

It seems to me that "only zero values override existing values" is the only criteria here: https://github.com/SCOREC/core/blob/master/phasta/phBC.cc#L181-L188

Prof. Sahni @onkarsahni suggests that we allow model faces to have ICs (in SimModeler) - to resolve conflict when two model regions sharing a model face have different ICs. One can even allow model edges and vertices to have ICs (e.g., when three or more model regions sharing a model edge or vertex have different ICs (i.e., each one has a different/unique value)).

cwsmith commented 6 years ago

With the exception of initial velocity, all IC appear to be scalar values:

https://github.com/SCOREC/core/blob/f12a2cfa9aeb72e188a8c6c23f734534598f58fa/phasta/phBC.cc#L248-L255

I can modify the SimModeler attdefs if that solution makes sense to everyone.

KennethEJansen commented 6 years ago

I think a modification is fine so long as the traditional use case is still supported without "heavy" additional attribution. By this I mean, I hope that any changes you make do not break the usual case of a single IC applied to model then gets applied to all entities of the model. My recollection is that this is the case and that IC's are currently not applied to model regions.

Regarding Cameron's note, I am a bit confused, the "order" of the variable (e.g., scalar, vector, tensor) should not matter. I take yang4's issue to be with what model entity can be given an IC attribute. I agree that this should be as simple as altering the attdef's file in simModeler in terms of creating the attribute files but I am less certain as to whether the logic to support querying of the IC attributes on entities lower than the model is implemented in Chef and further, whether inheritance is set up properly for that. My recollection is that BC's do have this worked out through up/down adjacencies. I would assume if this is not set up for IC's it should be fairly easy to do the same.

onkarsahni commented 6 years ago

I agree with Ken's comments:

I can provide full list of specific tags used in attdef file for ICs.

On 9/12/18 11:33 AM, Kenneth E. Jansen wrote:

I think a modification is fine so long as the traditional use case is still supported without "heavy" additional attribution. By this I mean, I hope that any changes you make do not break the usual case of a single IC applied to model then gets applied to all entities of the model. My recollection is that this is the case and that IC's are currently not applied to model regions.

Regarding Cameron's note, I am a bit confused, the "order" of the variable (e.g., scalar, vector, tensor) should not matter. I take yang4's issue to be with what model entity can be given a model attribute. I agree that this should be as simple as altering the attdef's file in simModeler in terms of creating the attribute files but I am less certain as to whether the logic to support querying of the IC attributes on entities lower than the model is implemented in Chef and further, whether inheritance is set up properly for that. My recollection is that BC's do have this worked out through up/down adjacencies. I would assume if this is not set up for IC's it should be fairly easy to do the same.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SCOREC/core/issues/176#issuecomment-420692950, or mute the thread https://github.com/notifications/unsubscribe-auth/AIiHePJa5sgZ8Ggobgo3HJgVJeQ454vkks5uaSllgaJpZM4WdSSZ.

cwsmith commented 6 years ago

@KennethEJansen I was checking the attribute definition to see how the 'applyScalar' code that Fan found applied.

To address the requirements I'm trying to understand how the boundary conditions are applied. Below are some notes.

The attribute loading process iterates over the following lists: https://github.com/SCOREC/core/blob/8b7c2602c1fb6d18ec440b691611fb815018ece2/phasta/phBC.cc#L220-L256 and the contents of the spj or smd to create a lookup table of attributes. My current understanding is that order matters in the attribute specification; for a given attribute-geometric model entity pair, the first specification of that pair is used and the rest are ignored unless they set the value of the attribute to zero.

During generation of phasta input structures, the call to getEssentialBCs loops over mesh vertices then applies the attribute's value with a call to applyEssentialBCs: https://github.com/SCOREC/core/blob/8b7c2602c1fb6d18ec440b691611fb815018ece2/phasta/phOutput.cc#L697-L706

As described in the function's comment, applyEssentialBCs is given a geometric model entity from which it does a depth first traversal of the upward adjacent geometric model entities. https://github.com/SCOREC/core/blob/8b7c2602c1fb6d18ec440b691611fb815018ece2/phasta/phBC.cc#L277-L305 At each upward adjacent entity in the traversal a check is made to (1) determine if the attribute is associated with the geometric model entity and (2) attempt to apply the attributes value. As Fan pointed out above, if the value was previously set for that entity and attribute, then it can only be overridden by a new instance of the same attribute that sets it to zero. If the attribute association is found the traversal up that adjacency branch stops.

Given this, I think if we use one attribute to set the IC on both regions, and then use a second attribute to set the IC on the geometric model face between them, then the above rules will correctly apply the IC.