XML In-Place Function Definitions

[cssherman]

Typically, functions are defined within the Functions block in the input xml file. However, ContactBase breaks this pattern by accepting a TableFunction as a child:

<Contact name="fractureContact" 
                penaltyStiffness="0.0e8" >
      <TableFunction  name="aperTable" 
                         coordinates = "{ -1.0e-3, 0.0}"
                         values      = "{  1.0e-6, 1.0e-4}"  />
</Contact>

Should we do one of the following?

• Allow this sort of in-place function definitions. This would require the parent object to manage the reading of the file, resulting in more code maintenance. However, it may make it easier to see the relationship between the table and the object in some cases.
• Enforce the existing convention where functions are defined within the Functions block, and are accessed by their name.

[andrea-franceschini]

For the contact relation I'm using I don't need any table of this sort, so I'm fine with the second solution, i.e., enforcing the usual way to access the tables.

[taojinllnl]

@joshua-white I have been testing/improving the hydrauFracture solver. My understanding is that in the current solver we still need this tableFunction when we assemble the Jacobian, or more specifically, when we calculate dAper_dU = contactRelation->dEffectiveAperture_dAperture( aperture[ei] ) * dGap_dU. Moreover, this tableFunction has an impact on convergence. For example, in the viscosity-dominated KGD case, certain combinations of coordinates and values in the tableFunction will make a problem non-convergent.

[joshua-white]

Hi @taojinllnl, the issue is not whether we need tables (we do) but more the syntax that we use to define them. You also bring up a separate issue (HF convergence) but let's revisit that with your PR discussion.

I also vote for the second solution.

[taojinllnl]

In the hydraulic fracture solver, extra pairs of values are pushed into the table function defined in the contact. And users have no way to see it. Also, it causes confusions, since the tableFunction defined in the hydraulicFracturing context is inconsistent with the tutorial. So we probably need to find a way to resolve this inconsistency between the tableFunction tutorial and the tableFunction in the context of HF. @cssherman @joshua-white

[cssherman]

In this case, my preference would be to hide the table function from the user altogether. Once we are comfortable with one that works in most cases, we could largely replace the table with a couple of key parameters (with appropriate defaults) that can be used to construct it.

[cssherman]

Also, I'd say that this usage is out of the scope for the function documentation. If an object is going to make modifications to a user-defined table, then the object's documentation is the correct space for this.