Variable substitution in XML DOM tree

[dschwen]

In Blackbear we need to be able to specify parameters in the MOSOE input file (this is required for using the stochastic methods module to launch many simulations). We currently use a hack, where a {variable} string in the XML code is replaced through string operation in a preprocessing step.

The XML spec has the concept of "entities" (&VARIABLE;) which unfortunately is not supported by the rapidxml library, so we need to stick with find/replace for now.

However, I'd like to perform that find/replace on individual attributes in the DOM tree. This would permit better error checking.

Right now, in Blackbear we cannot do proper error checking for missing or unused substitutions, because we cannot limit the find/replace to only the model subblock that is actually used.

[dschwen]

4b9a347 is a start.

It adds an optional argument to the NEML parse.. methods with a std::map<std::string, std::string> key value map. Every {key} get replace with its corresponding value. If a {variable} is found, where variable is not a key in the map, a verbose exception is thrown.

Optionally we could track which keys are used and throw if any are unused.

Let me know what you think.

[reverendbedford]

Apologies this took so long to get to. I guess I don't object to something like this, where we go in and alter the XML string. Let me take a look at the code and get the bindings working.

[reverendbedford]

Hmm, while I don't object to the approach this seems to be breaking the parse system. Fixing the bindings is trivially easy but the parse tests all fail with an empty substitutions map/dictionary. If you make a PR I can fix the bindings and show you what I mean.

[dschwen]

Yeah, there is more work to be done on this. Not quite ready. Alternative would be a better XML library with entity support.

…

On Tue, Apr 13, 2021, 8:24 PM Mark Messner ***@***.***> wrote: Hmm, while I don't object to the approach this seems to be breaking the parse system. Fixing the bindings is trivially easy but the parse tests all fail with an empty substitutions map/dictionary. If you make a PR I can fix the bindings and show you what I mean. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#100 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRMPVUKY75STLWNT4FPRDTIT4F3ANCNFSM42JQOVEA> .

[reverendbedford]

Ironically I used to use libxml. But MOOSE folk asked me to switch to the header-only library back when Ben first integrated NEML into blackbear...

I would be okay going back to a nicer XML library. Past that this is about the only type of solution I can think of. I still need to get around to writing a serialization system, but my plan was just to go back from the objects to XML. So that wouldn't make this any easier.

[hugary1995]

How about using Hit? I know switching to a different format is a lot of work. But long-term this could minimize the maintenance cost.

[reverendbedford]

1. I finished the serialization support earlier this year.
2. It might be best to first refactor the stuff in parse.h and deparse.h to provide an object oriented interfaces to serialization and deserialization. In the first step that would be just transitioning over the current XML code. Then we could add in new implementations of the interface that target Hit instead of XML. That way I don't make anyone else unhappy, not that we have a ton of other users, by getting rid of XML.

[reverendbedford]

Alternatively, we could dump the problem into MOOSE. It should already possible to write a MOOSE action to construct a NEML model just using the C++ API directly. We could store that model in a UserObject or something and then link it into the MOOSE material.

Well I guess having a hit serialization/deserialization interface would make that task a whole lot easier in MOOSE anyway. So maybe the two approaches are fundamentally similar.

Either way, I'd like to be able to better integrate NEML into MOOSE without loosing the ability to compile it as a stand alone python package and provide UMAT/UMATERIAL inferfaces to Abaqus/ANSYS, because we do have actual users that want that particular interface to the library (ANSYS). It's something to think about how to do, particularly if I can figure out a good way to address the scalar real type issue as well.

[dschwen]

We just started moving model data out of source files into JSON data files.