Zodiac issueshttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues2021-12-16T21:44:32Zhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/19Transport coefficients in new cantera are wrong2021-12-16T21:44:32ZJames SutherlandTransport coefficients in new cantera are wrong## Description of the problem
Transport coefficients (viscosity, thermal conductivity) calculated via PoKiTT are wrong. I've tracked this down to the `polyfit` function inside cantera where the species viscosities and thermal conductiv...## Description of the problem
Transport coefficients (viscosity, thermal conductivity) calculated via PoKiTT are wrong. I've tracked this down to the `polyfit` function inside cantera where the species viscosities and thermal conductivities are fit to polynomials. The inputs to that function are all consistent, but the function returns different polynomial coefficients in Zodiac and PoKiTT.
Strangely, `PoKiTT` doesn't show this problem. It gets the expected result.
I suspect that other downstream usage (Wasatch, ODT) will have the same problem.
Note that the `polyfit` function calls through to the `Eigen` library, which Cantera builds internally. `SpatialOps` also builds `Eigen` internally. However, since it is a header-only library, I don't see how we could get a clash there...James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/18"make install" issue2021-09-26T02:16:12ZHang Zhou"make install" issueWhen running Zodiac cases on aurora:
* If using `make -j20` to compile, and getting the executable file `zodiac` in directory `build/src`. Then running `build/src/zodiac InputFile.yaml` works fine.
* However, if using `make -j20 install...When running Zodiac cases on aurora:
* If using `make -j20` to compile, and getting the executable file `zodiac` in directory `build/src`. Then running `build/src/zodiac InputFile.yaml` works fine.
* However, if using `make -j20 install`, and getting the executable file `zodiac` in both directories `build/src` and `build/bin`. Then running `build/bin/zodiac InputFile.yaml` gives the error of "*build/bin/zodiac: error while loading shared libraries: libyaml.cpp.so.0.7: cannot open shared object file: No such file or directory*".
This is probably because it is doing dynamic rather than static linking.James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/17steady_cv_ad_closed__Tpzvar takes too long to run2020-04-10T21:24:34ZJames Sutherlandsteady_cv_ad_closed__Tpzvar takes too long to runPlease shorten this test.Please shorten this test.Hang ZhouHang Zhouhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/15Restart2018-10-25T15:20:35ZMike HansenRestartAdd the option of specifying an existing Zodiac output database as input for temperature, pressure, and composition (mass fractions).Add the option of specifying an existing Zodiac output database as input for temperature, pressure, and composition (mass fractions).https://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/8Allow more options for inflow state specification2018-09-28T04:20:31ZJames SutherlandAllow more options for inflow state specificationCurrently, the inflow state is the same as the initial condition. We will probably want to support other options such as:
* [ ] constant values
* [ ] parametrically determined values (functions of the "grid" variables)
* [ ] equilib...Currently, the inflow state is the same as the initial condition. We will probably want to support other options such as:
* [ ] constant values
* [ ] parametrically determined values (functions of the "grid" variables)
* [ ] equilibrium state? This would require an equilibrium solve.
* [ ] load from a previous zodiac run? This could be a way to get to the equilibrium state condition.https://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/14Add regression tests.2018-09-25T17:44:58ZJames SutherlandAdd regression tests.This is really important to preserve the integrity of the code base.
If we must, we can adopt a gold-standard approach. But could we do something like setting up an ignition calculation and spot-checking the temperature at a specific i...This is really important to preserve the integrity of the code base.
If we must, we can adopt a gold-standard approach. But could we do something like setting up an ignition calculation and spot-checking the temperature at a specific iteration count?James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/16Post processing problems?2018-04-24T18:17:02ZJames SutherlandPost processing problems?[This zip file](/uploads/7f6d50822540c2d522637ea2551ff0f6/methanol.zip) contains an input file as well as sample output from a steady-state calculation.
There are a few issues exposed by this:
1. Running
```
python ~/projects/Zodia...[This zip file](/uploads/7f6d50822540c2d522637ea2551ff0f6/methanol.zip) contains an input file as well as sample output from a steady-state calculation.
There are a few issues exposed by this:
1. Running
```
python ~/projects/Zodiac/postproc/zodiac_postproc.py -pv "T;lambda+"
```
launches a window but produces no results.
1. Running
```
python ~/projects/Zodiac/postproc/zodiac_postproc.py -pv "T;CH3OH"
```
does not work
Note that this does _not_ vary inlet temperature; rather, it varies the inlet composition. So the plot independent variable axis is also problematic. Note that we could add independent variable labels to the output database and pull them into the post processing.Elizabeth ArmstrongElizabeth Armstronghttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/13Fixed one sign for the matrix transformation2018-02-10T18:03:33ZHang ZhouFixed one sign for the matrix transformation- [x] In the transformation matrix, $`\frac{\partial T}{\partial \rho} = - \frac{e_N}{\rho c_v}`$. The sign should be negative. It is in the file "TransformationMatrixExpressions.h" Line 259.- [x] In the transformation matrix, $`\frac{\partial T}{\partial \rho} = - \frac{e_N}{\rho c_v}`$. The sign should be negative. It is in the file "TransformationMatrixExpressions.h" Line 259.Hang ZhouHang Zhouhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/12Allow the independent variables (the grid) to be written out to the output fi...2017-11-27T21:51:59ZJames SutherlandAllow the independent variables (the grid) to be written out to the output files.Example: if we have parametric variation of mixture fraction and temperature, we would want the values of those two quantities output as well.Example: if we have parametric variation of mixture fraction and temperature, we would want the values of those two quantities output as well.https://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/3Add GPU configure flag to build system2017-11-20T14:28:56ZJames SutherlandAdd GPU configure flag to build systemWhen auto-building upstream libs, we need to allow GPU-enabled builds.When auto-building upstream libs, we need to allow GPU-enabled builds.James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/7Initialization using SpatialOps::Grid is problematic2017-11-20T14:28:56ZJames SutherlandInitialization using SpatialOps::Grid is problematicZodiac uses `SVolField` variables as its field type. It is currently using `SpatialOps::Grid` to initialize the parametric variables over which the simulation is run.
There are a few problems with this:
* `SVolField` is a cell-cente...Zodiac uses `SVolField` variables as its field type. It is currently using `SpatialOps::Grid` to initialize the parametric variables over which the simulation is run.
There are a few problems with this:
* `SVolField` is a cell-centered variable, meaning that if we specify `n` points over `[min,max]`, we won't get a point at `min` and `max` - rather, they will be offset by half of the spacing.
* We may want to have log-spaced fields, or fields at specified values, etc. These will require initialization other than using `SpatialOps::Grid`
A possible solution that would allow us to leverage `SpatialOps::Grid` is to define a `Vertex` field type in SpatialOps that lives on vertices rather than volumes or faces. James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/1Add documentation for Zodiac2017-11-20T14:28:55ZJames SutherlandAdd documentation for ZodiacWe need a "manual" for Zodiac that should include:
* [x] The equations being solved
* [x] An overview of the solution method, with references to Mike's papers on \Psi-tc
* [x] Summary of input parameters and description of how to use ...We need a "manual" for Zodiac that should include:
* [x] The equations being solved
* [x] An overview of the solution method, with references to Mike's papers on \Psi-tc
* [x] Summary of input parameters and description of how to use zodiac
* [x] Instructions on using the post-processing tools.
We should write this in LaTeX, and then I can probably set up the CI to build the docs automatically.James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/2Add examples/tests to Zodiac2017-11-20T14:28:55ZJames SutherlandAdd examples/tests to ZodiacThis may include:
* [x] a few mechanisms
* [x] a few command line examples to run Zodiac. These can be attached as a comment on this issue.
@james can hook these into the CI once we have this ready.This may include:
* [x] a few mechanisms
* [x] a few command line examples to run Zodiac. These can be attached as a comment on this issue.
@james can hook these into the CI once we have this ready.James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/4More control over dumping fields to disk2017-05-19T09:18:36ZJames SutherlandMore control over dumping fields to diskThere are a few "modes" we may want to write information in:
1. **time-accurate** mode. In this case, we don't want information over dualtime iterations
1. **steady-state** mode. In this case, we may want information over dualtime it...There are a few "modes" we may want to write information in:
1. **time-accurate** mode. In this case, we don't want information over dualtime iterations
1. **steady-state** mode. In this case, we may want information over dualtime iterations
In addition, we will want the ability to dump information at **specified intervals**, not necessarily each time/dualtime step.James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/5Use input file rather than command line for problem specification.2017-05-19T09:18:36ZJames SutherlandUse input file rather than command line for problem specification.I personally prefer [yaml](http://www.yaml.org/refcard.html), as it is highly expressive and compact.
Using yaml will require:
* C++ yaml library for reading it in Zodiac. We can use the modified version I have inside the ODT or LBM...I personally prefer [yaml](http://www.yaml.org/refcard.html), as it is highly expressive and compact.
Using yaml will require:
* C++ yaml library for reading it in Zodiac. We can use the modified version I have inside the ODT or LBMS codes.
* [python yaml](http://pyyaml.org/) library for writing it from the web gui.
Things to do:
* [x] Cantera input file specification
* [x] Initialization of primitive variables & parameters through input file. See also issue #7
* [x] Time integrator parameters
* [x] Output fields selection
* [x] lock fields that are requested for output
* [x] allow dualtime and real time output intervals to be specified. Dualtime perhaps should only keep the most recent entries?
* [x] allow override of field names in output
Note that the residence time cannot presently be specified as a parametric variable - only a constant. Mike has some changes in the pipeline to relax this.
James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/6Set zero ghosts by default when building ExprLib.2017-05-19T09:18:36ZJames SutherlandSet zero ghosts by default when building ExprLib.James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/9Move lingering parameters into the input file2017-05-19T09:18:36ZJames SutherlandMove lingering parameters into the input fileThere are a few parameters that should be moved to the input file from where they are currently in `ReactorEnsembleSpecs`
* `tauMix` - this will need to wait until Mike reworks the matrices in Zodiac.
* `h`
* `radius`
* `SoV`
* `Tin...There are a few parameters that should be moved to the input file from where they are currently in `ReactorEnsembleSpecs`
* `tauMix` - this will need to wait until Mike reworks the matrices in Zodiac.
* `h`
* `radius`
* `SoV`
* `Tinf`
Several of these have to do with the convective heat transfer model. Not sure how we want to handle that. We should have a discussion...https://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/10Autobuild failure2017-05-19T09:18:36ZJames SutherlandAutobuild failureCloning a clean Zodiac repo and letting auto-build go leads to the following error on my mac. Line 147 is `find_package( PoKiTT REQUIRED PATHS ${TPL_DIR}/share )` and Zodiac simply can't find PoKiTT.
Auto-build works fine for me on Pris...Cloning a clean Zodiac repo and letting auto-build go leads to the following error on my mac. Line 147 is `find_package( PoKiTT REQUIRED PATHS ${TPL_DIR}/share )` and Zodiac simply can't find PoKiTT.
Auto-build works fine for me on Prism.
I had Josh try auto-building Zodiac and he arrived at the same issue.
![Screen_Shot_2016-12-06_at_2.11.42_PM](/uploads/dd73ba996d1faefa08030d269783e5c3/Screen_Shot_2016-12-06_at_2.11.42_PM.png)James SutherlandJames Sutherlandhttps://gitlab.multiscale.utah.edu/common/Zodiac/-/issues/11Use an expression for tau-mix rather than a value.2017-05-19T09:18:36ZJames SutherlandUse an expression for tau-mix rather than a value.@mahanse made some changes in the matrix assembly stuff that should facilitate this.
There are two (I think) places to pay attention to:
1. [parse_reactor_parameters](src/parser/ParseInputFile.cpp#L185) in [ParseInputFile.cpp](src/p...@mahanse made some changes in the matrix assembly stuff that should facilitate this.
There are two (I think) places to pay attention to:
1. [parse_reactor_parameters](src/parser/ParseInputFile.cpp#L185) in [ParseInputFile.cpp](src/parser/ParseInputFile.cpp). You will need to create the expression for tau_mix there. For now, we can simply support constant expressions. Then the parser won't need to change at all.
1. Where the [matrix is constructed](src/ConstantVolumeMixingConvection.cpp#L259).
Once this is done, we can remove [ReactorEnsembleSpecs](src/parser/ParseInputFile.h#L27) and change [parse_reactor_parameters](src/parser/ParseInputFile.h#L42) to a `void` function.James SutherlandJames Sutherland