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/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/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/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 Sutherland