Dr. Aagaard, @baagaard
As discussed the other day, I am using pylith::bc:NeumannTimeDependent to specify the neumann BC in an MMS testing version of the Terzaghi problem. I am still a little unclear how the auxiliary field data is passed to the BC variable. Going on the example put forth for the DirichletUserFn objects, the assignment setup I have at the moment is as follows:
// Y Positive Traction
_bcTraction_ypos->useInitial(true);
_bcTraction_ypos->useRate(false);
_bcTraction_ypos->setScaleName("pressure");
_bcTraction_ypos->setMarkerLabel("ypos");
_bcTraction_ypos->setSubfieldName("displacement");
I know something needs to be added to take the place of the setUserFn call for DirichletUserFn, in order to specify values, however I am not sure the syntax required to replicate what would be in a .cfg file.
I would love some insight into what I hope is a minor bump in the road.
Thank you,
Robert
The bc::NeumannTimeDependent object inherits from bc::BoundaryCondition which inherits from problem::Physics. To find these yourself, just follow the inheritance as given in the header (.hh) files. The “setters” you will want to call are:
Implemented in NeumannTimeDependent:
-
setTimeHistoryDB() if applicable
useInitial()useRate()useTimeHistory()setScaleName()
Implemented in BoundaryCondition:
setMarkerLabel()setSubfieldName()setRefDir1()setRefDir2()
Implemented in Physics:
setNormalizer()setAuxiliaryFieldDB()-
setAuxiliaryFieldSubfieldDiscretization() for each subfield in the auxiliary field
You are already calling most of these, so it is just adding calls to the ones you are missing.
You should be able to use the default reference directions (used to determine the tangential directions) and not have to call setRefDir1() and setRefDir2() (I included those for completeness).
Apologies in advance if some of these are stupid questions, but I am still unclear about a bit.
I am unsure about setting the AuxiliaryFieldDB for the neumann BC. I believe the only example of an AuxiliaryFieldDB in the MMS tests available is that where the material parameters are setup. Using your example from the IncompressibleElasticity MMS tests, as well as the [assumed] precedent from the .cfg files, I am still not exactly sure how the equivalent of setting something like “spatialdata.spatialdb.UniformDB” is located/accomplished.
Continuing from the IncompressibleElasticity example, I am also going to guess that a separate (from the material properties) and new auxDB will be required; will this also be of the form spatialdata::spatialdb::UserFunctionDB? If so, will this also require its own variables for auxSubfields, auxDiscretizations, and the same setup process in the base (TestIncompressibleElasticity.cc, for example) as for the auxDB for the material properties? Similarly, will the pylith::topology::Field::Discretization values need to be updated for each element class, as in the specific examples?
Apologies again, this setup process is a bit confusing, for me, at least.
Robert
Yes, the Neumann BC setup for an MMS test closely follows that of the bulk material. It has its own spatial database for the auxiliary field. In the MMS tests we use the UserFunctionDB, which is an analytical function (again, see the material for examples). For the auxiliary field you will need to specify the discretization of each subfield (initial value, rate value, etc) as is done for the material.
I hate to have to follow up here again, but perhaps it will serve to aid for posterity’s sake.
I have followed the example that you use for the fault setup and material setup in the MMS testing where it was relevant. My example compiles, however for the test cases where the field discretization differs from what is set as the default value (say for an element of type TriP2), it does not appear to update the neumann boundary condition. A hard hack where TestPoroelasticity.cc was edited to print out basisOrder and quadOrder values in then loop where the setAuxiliarySubfieldDiscretization() call is given for the neumann BC produces the correct values, however these do not seem to be given to the neumann BC. I surmise this from the outputted error message (an example):
2) test: pylith::mmstests::TestIsotropicLinearPoroelasticity_Terzaghi_QuadQ3::testResidual (E)
uncaught exception of type std::exception (or derived).
- Quadrature order of subfields in auxiliary field 'NeumannTimeDependent auxiliary field' must all match the quadrature order in the target subfields 'solution'. Expected quadrature order of 3, but subfield 'initial_amplitude' has a quadrature order of 1.
This error message is produced by pylith::topology::FieldOps::checkDiscretization(solution, *auxiliaryField); within the pylith::bc::NeumannTimeDependent::createAuxiliaryField(const pylith::topology::Field& solution, const pylith::topology::Mesh& domainMesh) function from NeumannTimeDependent.cc.
Is there some call to setup a NeumanTimeDependent BC that I am missing? I have included the specific MMS test file (TestIsotropicLinearPoroelasticity_Terzaghi.cc), as well as all the relevant .cc and header files up the chain, following your MMS example from Incompressible Elasticity. I don’t entirely understand the process followed in the overall MMS test structure, so any help would be appreciated.
RobertTestIsotropicLinearPoroelasticity_Terzaghi.zip (9.7 KB)
Is this checked in to GitHub? It is easiest to provide a link to the code there.
The NeummanTimeDependent auxiliary field has a set of subfields from which it constructs the tangential and normal components that are applied at any given time step. See https://github.com/rwalkerlewis/pylith/blob/rlwalker/feature-poroelasticity/libsrc/pylith/bc/NeumannTimeDependent.cc#L258. When you set the discretization for the auxiliary field, you need to set the set the discretization for all of these subfields that you use. For example, if you use an initial amplitude, then you need to set the discretization for the initial_amplitude subfield (see the error message).
Important: There are a number of “extra”, machine-dependent files that have been checked in to the poroelasticity repo. These include .deps, .libs directories and .o files. These should all be removed from the repo. The repo should only include source files, input data files, and files needed to build the machine dependent files (like Makefile.am files).