-
Notifications
You must be signed in to change notification settings - Fork 6
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
ABC Simulator #13
ABC Simulator #13
Conversation
Hmm the Travis tests failed due to an import error from RMG-Py even though the master branch of RMG-Py passes all tests. I also tried running
I must be missing something obvious. Can you help me understand why these imports are failing? |
T3 uses RMG's binaries from conda... |
Sorry what files must we update in a separate PR? I'm not seeing where the RMS binaries are specified. |
I had a typo, it's RMG, not RMS. I'll make the PR |
Okay thanks for making the PR. Admittedly I'm still confused where RMG's conda binaries entered the travis build so I'll learn from your PR |
@alongd Can you review this PR when you get a chance? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this addition, introducing ABC into T3!!
I added some comments, most are minor.
tandem/sa/factory.py
Outdated
run_directory: str, | ||
input_file: str, | ||
threshold: Optional[float] = 0.001, | ||
verbose: Optional[bool] = True, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also need to add SA tolerances, see http://reactionmechanismgenerator.github.io/RMG-Py/users/rmg/input.html#simulator-tolerances
Let's asses what parameters RMS/Cantera require, and make sure we have them in out SAAdapter class. I think the most complicated thing is the reactor type: for RMG we simply use the reactor type from the input file, but here we should let the user specify how to simulate and run SA. |
Thank you for the PR. I totally support the transition to adapters. However, since sensitivity is also a simulation just with more things to calculate, I don't know if you agree that we should have a simulation class (adapter) first and build SA adapter on that. Below is a link a cantera sensitivity input example: Besides, I saw there is an argument (input_file), do we want to pursue a workflow of writing the input file first and then apply it to this SA factory, or it is just the input_file of RMG we used to generate the model? If the first case, the observable list can be removed (included in the input file). I think it introduces more flexibility. For example, I use range reactor in the model generation, while using a range of different conditions to do sensitivities. Besides, adiabatic conditions are also something I considered for sensitivity. Besides, in combustion community, sensitivity analysis on ignition delay is another thing wanted. This is probably also something we want to add into consideration. So, since we want to build input_files, we need to have a template write. (Jinja2 is something we want to pursue, I guess. Its inheritance function is useful). If the second case, I feel that we will be limited, but probably let me know your reason first. |
good point @xiaoruiDong, let's make a SimulateAdapter instead, we could have a bool flag for requesting SA in addition. Regarding the other points, we're just starting to discuss how to use Cantera and RMS, this part isn't ripe yet. Yes, it's possible to ask the user to supply an additional script for the simulation, specifying the reactors. |
Thank you both for this valuable feedback! I agree that the first case you describe offers better generalizability. I'll start working on a new branch called I have some clarifying questions for you both:
|
I was in the process of addressing Alon's comments so I just pushed the changes for all resolved conversations |
I agree with the first approach. We could have one (ABC) class, say SimulateAdaptor, that has many methods such as SA, UA, species profiles, fluxes... and at the core of all these features (I think) is simulating the reactor(s). |
I see. Thanks for clarifying. So would simulate just be an additional method that SA, UA, etc would call? As another question, how much flexibility are we looking for? Would SA, UA, etc actually be abstract methods in an ABC SimulateAdapter? Say we have 3 adapters: RMG, RMS, Cantera. Each has methods for simualte, SA, UA, etc. Normally, we would use the factory to create one instance of the needed adapter. I'm thinking it would be cumbersome for a user to simulate with Cantera and do SA with RMS with this set up. But perhaps this isn't necessary? |
Codecov Report
@@ Coverage Diff @@
## master #13 +/- ##
==========================================
+ Coverage 44.18% 49.46% +5.28%
==========================================
Files 4 8 +4
Lines 817 849 +32
Branches 238 238
==========================================
+ Hits 361 420 +59
+ Misses 400 363 -37
- Partials 56 66 +10
Continue to review full report at Codecov.
|
@alongd Can you take a look at this draft of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! I added a minor comment, let's work on the input file PR (I'll push soon) so we'll have the correct inputs for these adapters
tandem/simulate/rmg_simulator.py
Outdated
sa_rtol (Optional[float]): The relative tolerance used when running SA. | ||
verbose (Optional[bool]): Whether or not to log to file. | ||
|
||
======================= ====== ==================================================== |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't use this style for attributes in T3 (we do in RMG), you can have an Attributes:
section in a similar format to Args:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for reviewing! I just pushed the updated format for documenting the attributes. I think the pyrms simulator adapter is ready as well, just needs SA to be working in rms. I'm happy to help with the T3 input file in the meantime :)
tandem/simulate/rmg_simulator.py
Outdated
|
||
Returns: | ||
A SA dictionary, whose structure is given below. | ||
sa_dict = { 'thermo' : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
excellent, thanks!
Run SA using the simulate adapter rather than the previous `run_sa()` method. Remove code from `run_sa()` that is now part of the `get_sa_coefficients()` method in the RMG adapter. Remove the corresponding imports in main.py that have now been moved to the RMG Simulator Adapter.
Update environment.yml to include pyrms and Matt's channel Add scripts to organize the installation of ARC, Julia 1.4, RMS, and pycall. Note: the pyrms conda package is currently for v0.2.1. SA is functional only on v0.3.0 or later and we must use RMS v0.3.2 to fix the constantPDomain error
@kspieks, everything looks good to me. Are we good to merge this in? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kspieks, Thank you. This is a well deserved merge: a seminal PR which reflects a significant improvement in T3's abilities and flexibility. Thanks for the professional work! 🥇
This PR creates a template for adding SA adapters. It implements SA with RMG. I welcome all feedback and look forward to your comments :)