Skip to content
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

Draft
wants to merge 62 commits into
base: main
Choose a base branch
from

Conversation

helen-brooks
Copy link

@helen-brooks helen-brooks commented Jan 15, 2024

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 the Factory 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 the Model class which ingests a Factory 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 into SyntaxPath objects and store in a SyntaxRegistry. From the registry entries, SyntaxBlock objects may be created, which roughly correspond to a "block" of MOOSE input file syntax.
  • param.py : defines MooseParam class which represents a single parameter affiliated with a given MOOSE object.
  • base.py : defines MooseBase class which the abstract base class for all MOOSE objects (supercedes the previously-named Catbird class).
  • string.py : defines MooseString class, intended to be a mixin for MooseBase derivatives to help with printing to file.
  • obj.py : defines MooseObject class, intended to represent Moose syntax that is affiliated with a "type" (e.g. FileMesh for Mesh block)
  • action.py : defines MooseAction class, intended to represent Moose Action syntax (e.g. CreateDisplacedProblemAction for Mesh block)
  • collection.py : defines MooseCollection 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.

@pshriwise
Copy link
Owner

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?

@helen-brooks
Copy link
Author

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.

@helen-brooks
Copy link
Author

helen-brooks commented Feb 9, 2024

@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?

catbird/utils.py Outdated Show resolved Hide resolved
@helen-brooks
Copy link
Author

@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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants