Temperature and density fields#173
Conversation
Added in the BEAVRS model with the D-bank partially inserted. Also fixed a flaw in the geometry where the outermost cell was defined such that there could be a rare particle lost between it and the geometry boundary.
Field which have values that are piecewise constant. Endowed with a distance calculation. Added a simple version which allows a lattice to be specified.
Can overlay temperature and density fields on the geometry. Supports both surface and delta tracking.
|
I have also added a new map to allow tallying on a given field definition. Currently this is limited to pieceConstantFields until we unify the interface. |
There was a problem hiding this comment.
That was a lot!!!! The nuclear data bit seemed to make sense but I have to admit it will be good to give it another look post revisions.
There are a couple of bigger issues that I wrote in specific comments, but in general it looks good! It was a massive effort so well done.
Geometry/Fields/ScalarFields/PieceConstantFields/pieceConstantField_inter.f90
Outdated
Show resolved
Hide resolved
Geometry/geometryStd_class.f90
Outdated
|
|
||
|
|
||
| ! This check is really awful - can we do something better? | ||
| else if (fieldDist < dist .and. abs(fieldDist - dist) > 10*NUDGE) then ! Stays within the same cell, but crosses field boundary |
There was a problem hiding this comment.
Can't you just do
else if (maxDist < dist .and. maxDist >= fieldDist)?
in this case you're not crossing any geometrical boundary but a field boundary.
Also removed fieldMaps. Unnecessary for the moment.
|
Made some changes to this:
Otherwise, I think I have addressed most of the comments. |
valeriaRaffuzzi
left a comment
There was a problem hiding this comment.
All good to merge! Excited to have multi-physics coupling soon!
Using the pieceConstantField, I have added the capability to super-impose temperature and density-scaling fields on the geometry. Both surface and delta tracking agree with each other for temperature and density changes, and they agree with reference calculations without imposed fields.
The distance calculations are done inside move. They work well for the most part, with one uncomfortable bit: fuzziness needed to be added to ensure that distance to the field does not take precedence over distance to the boundary. If there are any better suggestions for this it would be great.
This necessitated make the initMajorant function part of the nuclearDatabase, allowing it to be called in the physicsPackages which can receive the relevant field information from geometry.
I have updated the docs and added an integration test to geometry for obtaining values from the fields and distance calculations.