-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Generalise catbird to support generic MOOSE input deck creation #5
base: main
Are you sure you want to change the base?
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 <[email protected]>
@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 theFactory
class 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 theModel
class which ingests aFactory
and 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 intoSyntaxPath
objects and store in aSyntaxRegistry
. From the registry entries,SyntaxBlock
objects may be created, which roughly correspond to a "block" of MOOSE input file syntax.param.py
: definesMooseParam
class which represents a single parameter affiliated with a given MOOSE object.base.py
: definesMooseBase
class which the abstract base class for all MOOSE objects (supercedes the previously-namedCatbird
class).string.py
: definesMooseString
class, intended to be a mixin forMooseBase
derivatives to help with printing to file.obj.py
: definesMooseObject
class, intended to represent Moose syntax that is affiliated with a "type" (e.g. FileMesh for Mesh block)action.py
: definesMooseAction
class, intended to represent Moose Action syntax (e.g. CreateDisplacedProblemAction for Mesh block)collection.py
: definesMooseCollection
class, 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.