initial condition ambiguity by using SimModeler

[yangf4]

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]

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

core/phasta/phBC.cc

Lines 248 to 255 in f12a2cf

	static KnownBC const solutionBCs[7] = {
	{"initial pressure", 0,-1, applyScalar},
	{"initial velocity", 1,-1, applyVector},
	{"initial temperature", 4,-1, applyScalar},
	{"initial scalar_1", 5,-1, applyScalar},
	{"initial scalar_2", 6,-1, applyScalar},
	{"initial scalar_3", 7,-1, applyScalar},
	{"initial scalar_4", 8,-1, applyScalar},

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

[KennethEJansen]

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]

I agree with Ken's comments: * We should keep (or "preserve") the traditional use case at model or region level (likely keep it as it is, i.e., require no modifications and backward compatibility). * It should be a simple modification attdef's file. * Inheritance logic used for BCs should be applicable/transferable for ICs (if it is not already used) I can provide full list of specific tags used in attdef file for ICs. - Onkar

…

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 <#176 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIiHePJa5sgZ8Ggobgo3HJgVJeQ454vkks5uaSllgaJpZM4WdSSZ>.

[cwsmith]

@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:

core/phasta/phBC.cc

Lines 220 to 256 in 8b7c260

	static KnownBC const essentialBCs[7] = {
	{"density", 0, 0, applyScalar},
	{"temperature", 1, 1, applyScalar},
	{"pressure", 2, 2, applyScalar},
	/* these conditions are too complex to be dealt with
	here, see phConstraint.cc */
	//{"comp1", 3, 3, applyComp1},
	//{"comp3", 3, 3, applyComp3},
	{"scalar_1", 12, 6, applyScalar},
	{"scalar_2", 13, 7, applyScalar},
	{"scalar_3", 14, 8, applyScalar},
	{"scalar_4", 15, 9, applyScalar},
	};
	static KnownBC const naturalBCs[11] = {
	{"mass flux", 0, 0, applyScalar},
	{"natural pressure", 1, 1, applyScalar},
	{"traction vector", 2, 2, applyVector},
	{"heat flux", 5, 3, applyScalar},
	{"turbulence wall", -1, 4, applyBit},
	{"scalar_1 flux", 6, 5, applyScalar},
	{"scalar_2 flux", 7, 6, applyScalar},
	{"scalar_3 flux", 8, 7, applyScalar},
	{"scalar_4 flux", 9, 8, applyScalar},
	{"surf ID", -1,-1, applySurfID},
	{"traction vector melas", 10, 9, applyVector},
	};
	static KnownBC const solutionBCs[7] = {
	{"initial pressure", 0,-1, applyScalar},
	{"initial velocity", 1,-1, applyVector},
	{"initial temperature", 4,-1, applyScalar},
	{"initial scalar_1", 5,-1, applyScalar},
	{"initial scalar_2", 6,-1, applyScalar},
	{"initial scalar_3", 7,-1, applyScalar},
	{"initial scalar_4", 8,-1, applyScalar},
	};

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:

core/phasta/phOutput.cc

Lines 697 to 706 in 8b7c260

	apf::MeshIterator* it = m->begin(0);
	while ((v = m->iterate(it))) {
	gmi_ent* ge = (gmi_ent*) m->toModel(v);
	apf::Vector3 x;
	m->getPoint(v, 0, x);
	ibc = 0;
	for (int j = 0; j < nec; ++j)
	bc[j] = 0;
	//bool hasBC = applyEssentialBCs(gm, ge, bcs, x, bc, &ibc) && bcs.fields.count("material type");
	bool hasBC = applyEssentialBCs(gm, ge, bcs, x, bc, &ibc);

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.

core/phasta/phBC.cc

Lines 277 to 305 in 8b7c260

	/* starting from the current geometric entity,
	try to find attribute (kbc) attached to
	geometric entities by searching all upward
	adjacencies.
	we use depth first search starting from
	the model entity of origin, using upward
	adjacencies as graph edges.
	if an attached attribute is found on an
	entity, the search continues without looking
	at its upward adjacencies */
	static bool applyBC(gmi_model* gm, gmi_ent* ge,
	FieldBCs& bcs,
	apf::Vector3 const& x,
	KnownBC const& kbc,
	double* values, int* bits)
	{
	double* v = getBCValue(gm, bcs, ge, x);
	if (v) {
	kbc.apply(values, bits, kbc, v);
	return true;
	}
	bool appliedAny = false;
	gmi_set* up = gmi_adjacent(gm, ge, gmi_dim(gm, ge) + 1);
	for (int i = 0; i < up->n; ++i)
	if ( applyBC(gm, up->e[i], bcs, x, kbc, values, bits) )
	appliedAny = true;
	gmi_free_set(up);
	return appliedAny;
	}

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.