WIP: Generalise catbird to support generic MOOSE input deck creation#5
WIP: Generalise catbird to support generic MOOSE input deck creation#5helen-brooks wants to merge 62 commits intopshriwise:mainfrom
Conversation
…e to delete this later
|
Really cool to see this working for generic types in MOOSE! I think I should've asked more questions about how to build up an input from scratch on our call. My plan was to start contributing to the tests as a way of understanding the new API and internals, but I didn't get very far. Would you be up for updating the README w/ a few usage examples I can build off of? |
Sorry for being slow to reply. Most certainly. The current local examples I have are actually just random sytax and I haven't checked for their being valid MOOSE files. My next step will be to make a just a simple thermal problem that does run, then that could be the basis for some sort of regression test. |
…ttempt to cast as correct type
|
@pshriwise README added, worked example added, and description updated. Still a few to-dos outstanding, so I've not removed the "WIP", but it's probably worth a look now? |
Co-authored-by: Patrick Shriwise <pshriwise@gmail.com>
|
@pshriwise sorry for being slow :/ but thank you ever so much for your fix, same json reader issue hit me as soon as I updated my rather out-of-date MOOSE. However, I'm now on head commit of MOOSE master and my little thermal example still runs :) |
Purpose
Generalises the principle idea from catbird into a general purpose python library to create python objects from arbitrary MOOSE syntax, and produce working input decks.
Files and key classes
Here's an explanation of what's in each file (in a hopefully fairly logical order).
The two key files are:
factory.py: Defines theFactoryclass which converts dumped JSON syntax from a MOOSE app into python objects. Also implements logic to mix multiple types into a single class (e.g. a Mesh input block requires the intersection of object, action and collection functionality).model.py: Defines theModelclass which ingests aFactoryand assembles a boilerplate MOOSE model, intended to represent an input deck.The rest of the library consists of:
utils.py: provides the utilities to read and write from JSON, plus the original functionality to dump a MOOSE app's syntax as JSON.syntax.py: provides the functionality to parse the JSON syntax recursively: flattens the heirarchical structure intoSyntaxPathobjects and store in aSyntaxRegistry. From the registry entries,SyntaxBlockobjects may be created, which roughly correspond to a "block" of MOOSE input file syntax.param.py: definesMooseParamclass which represents a single parameter affiliated with a given MOOSE object.base.py: definesMooseBaseclass which the abstract base class for all MOOSE objects (supercedes the previously-namedCatbirdclass).string.py: definesMooseStringclass, intended to be a mixin forMooseBasederivatives to help with printing to file.obj.py: definesMooseObjectclass, intended to represent Moose syntax that is affiliated with a "type" (e.g. FileMesh for Mesh block)action.py: definesMooseActionclass, intended to represent Moose Action syntax (e.g. CreateDisplacedProblemAction for Mesh block)collection.py: definesMooseCollectionclass, intended to represent a grouping of objects or actions (e.g. Variables, Kernels, BCs...)legacy.py: see below.Usage
See README.md
TODO
Things I've not attended to yet because they require discussion.
Legacy code
There's some intermediate legacy code in legacy.py that I kept while I was still trying to be backwards compatible. I don't know if there's anything in here that you wish to retain.
Tests
Will most likely be broken, and need updating... But want to discuss first what is appropriate in terms of fixing tests that may now be obsolete.
Unsupported syntax
There's a small subset of syntax that I can't support yet, but which notably includes "MasterAction" style syntax for certain modules such as TensorMechanics. There isn't a specific reason for this, other that I haven't got to it yet.