Temperature and density fields #173

ChasingNeutrons · 2025-08-24T20:35:26Z

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.

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.

…to develop

Can overlay temperature and density fields on the geometry. Supports both surface and delta tracking.

ChasingNeutrons · 2025-08-29T16:09:12Z

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.

valeriaRaffuzzi

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.

valeriaRaffuzzi · 2025-12-16T11:28:29Z

ParticleObjects/particle_class.f90

    real(defReal)              :: time      ! Particle time point

+    ! Information passed from geometry
+    real(defReal)              :: T = -INF   ! Local temperature


You could use a consistent undefined value in between places: it is -INF here but, for example, -ONE in fissionSource_class.f90 (line 227)

Yes, I should define a 'NO_TEMPERATURE' and 'NO_DENSITY' I think.

valeriaRaffuzzi · 2025-12-16T11:37:39Z

docs/User Manual.rst

+  in different materials, or uniformly across all materials.
+
+  - shape: (x y z) array of integers, stating the numbers of x, y and z
+    elements of the field. For a 2D field, one of the entries has to be 0


I thought only z was allowed to be 0

valeriaRaffuzzi · 2025-12-16T11:49:22Z

docs/User Manual.rst

+  - names of each material: a map, named after every material present in the materials list. 
+    The entries of the map are the values that the field takes in that material in that
+    element of the field. The order is: increasing x, increasing y and then increasing z.
+  - default: the value taken by the field when a point is either outside of the field or


There should probably be a default for each material.
In the case of density, the default could be set to 1.0 for all materials but this wouldn't be possible for the temperature.

I may need to think about a way of doing this in cases where there are many materials. The most obvious use case that I see at the moment is that there are ~2 materials one would care to modify (fuel, coolant). The others would not have any modifications, i.e., they would use the default input values, corresponding to setting a default of a negative number, which does not perform any modification. Maybe there is a question of how to make this as userfriendly as possible, e.g., the default default is 'do nothing'.

Oh, I think I understand better now. You mean for each material specified in the field definition. This does make sense; the default option was made for anything that doesn't correspond to what's in the map (either in space or material). There is maybe quite a multiplicity of options to consider...

NuclearData/nuclearDatabase_inter.f90

valeriaRaffuzzi · 2025-12-16T14:46:42Z

Geometry/Fields/ScalarFields/PieceConstantFields/pieceConstantField_inter.f90

+    if (dict % isPresent('path')) then
+      call dict % get(path, 'path')
+      call self % init_file(path)
+    else
+      call self % init_dict(dict)
+    end if
+
+  end subroutine init
+
+  !!
+  !! Initialise field from a file
+  !!
+  !! Args:
+  !!   file [in] -> Path to a file containing the field definition
+  !!
+  subroutine init_file(self, path)
+    class(pieceConstantField), intent(inout) :: self
+    character(pathLen), intent(in)           :: path
+    type(dictionary)                         :: dict
+
+    call fileToDict(dict, path)
+    call self % init(dict)
+
+  end subroutine init_file


Suggested change

if (dict % isPresent('path')) then

call dict % get(path, 'path')

call self % init_file(path)

else

call self % init_dict(dict)

end if

end subroutine init

!!

!! Initialise field from a file

!!

!! Args:

!! file [in] -> Path to a file containing the field definition

!!

subroutine init_file(self, path)

class(pieceConstantField), intent(inout) :: self

character(pathLen), intent(in) :: path

type(dictionary) :: dict

call fileToDict(dict, path)

call self % init(dict)

end subroutine init_file

if (dict % isPresent('path')) then

call dict % get(path, 'path')

call fileToDict(dict, path)

end if

call self % init_dict(dict)

end subroutine init

And then you remove init_file, you have init public and init_dict private

valeriaRaffuzzi · 2025-12-16T15:08:42Z

NuclearData/ceNeutronData/ceNeutronCache_mod.f90

+  !!   T   -> temperature of the cross section
+  !!   rho -> density scaling of the cross section


Should T and rho have been added to cacheSingleXS?

valeriaRaffuzzi · 2025-12-16T15:10:58Z

NuclearData/ceNeutronData/ceNeutronDatabase_inter.f90

    ! Procedures implemented by a specific CE Neutron Database
    procedure(updateMajorantXS), deferred     :: updateMajorantXS
-    procedure(updateTotalMatXS), deferred     :: updateTrackMatXS
+    procedure(updateTrackMatXS), deferred     :: updateTrackMatXS


How could we have survived with this massive typo?

valeriaRaffuzzi · 2025-12-16T17:57:07Z

Geometry/geometryStd_class.f90

-
+
+    ! 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


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.

valeriaRaffuzzi · 2025-12-16T18:10:42Z

NuclearData/ceNeutronData/ceNeutronMaterial_class.f90

  !!   Returns nucIdx <= if material is not fissile
  !!
-  function sampleFission(self, E, rand) result(nucIdx)
+  function sampleFission(self, E, temp, rho, rand) result(nucIdx)


I think all these sampling functions are not used to be honest...

ChasingNeutrons added 15 commits January 22, 2025 17:15

Fix to keff for MG scattering

83df212

BEAVRS_HZP and geometry fixes

0791fe2

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.

Merge branch 'CambridgeNuclear:main' into develop

8e51a1c

Added distance calculation to some tallyMaps

4533140

Added piecewise constant fields

6de5943

Field which have values that are piecewise constant. Endowed with a distance calculation. Added a simple version which allows a lattice to be specified.

Merge branch 'develop' of https://github.com/ChasingNeutrons/SCONE in…

cdd6090

…to develop

PieceConstant fields take coordList

1a63bfa

Merge branch 'develop' into discontField

f49eb04

Silly BEAVRS fix...

53a35b5

Fixes to silly things

8eaabad

First changes, not complete

a3247d4

Tweaks to data

1871364

Something is broken :/

7235f62

Major fixes - not there yet

6e354c3

Temperature and density fields

57eef72

Can overlay temperature and density fields on the geometry. Supports both surface and delta tracking.

ChasingNeutrons requested review from Mikolaj-A-Kowalski and valeriaRaffuzzi August 24, 2025 20:35

ChasingNeutrons added the enhancement New feature or request label Aug 24, 2025

ChasingNeutrons added 6 commits August 24, 2025 22:29

Added integrationTest data

fd22103

Removing accidentally added files...

4cb9a4b

Most of fieldMap with tweaks to fields

e160db5

Finalise map for tallying on pieceConstant fields

8f9efaf

Updated docs

58fa987

Fix tests and docs

298b1fb

ChasingNeutrons added 5 commits December 7, 2025 20:15

Field interface accepts particles or coords

fa7683a

Merge branch 'fixWW' into discontField

8d40441

Updating field interface

13c1ecb

Merge branch 'discontField' into temp_and_density_fields

ff7d362

Moving the PCField factory

028775a

ChasingNeutrons added 2 commits December 15, 2025 20:36

Merge branch 'develop' into temp_and_density_fields

568c4aa

Removing merge artefacts

a995272

valeriaRaffuzzi requested changes Dec 16, 2025

View reviewed changes

		!! T -> temperature of the cross section
		!! rho -> density scaling of the cross section



		! 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

Temperature and density fields #173

Are you sure you want to change the base?

Temperature and density fields #173

Uh oh!

Conversation

ChasingNeutrons commented Aug 24, 2025

Uh oh!

ChasingNeutrons commented Aug 29, 2025

Uh oh!

valeriaRaffuzzi left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

valeriaRaffuzzi left a comment •

edited

Loading