changes in temperature behavior?

[guadabsb15]

I observed the Temp field changing from November to the present running the same setup. I don't see appreciable changes in other fields like density and magvel at the same simulation time.

Based on the test suite list in (Castro/Util/regression_testing/hash_pairings.txt), the two changes were introduced on date 2016-12-01-001 and 2017-01-10-001. The following table shows the Temp field before this changes and then at each of the previous dates in chronological order.

with reflux	update_sources_after_reflux = 0	do_reflux = 0

The details of the two dates are:

1. 2016-12-01-001

   • Castro git hash: 8f17e0c8bd7209fc0567bb935171c01ff66e7f64
   • BoxLib git hash: 3b82103657a52b7fce8ad6ac5d5743a931c92596
   • Microphysics git hash: ccc4cdc6d8f12b7ea5641cca5adaf433b8d22e02

2. 2017-01-10-001

   • Castro git hash: 9b976b30de6c692aa070f2fce220d46a55eea521
   • BoxLib git hash: 12fe9c19a66d0a7b68466f2a8915f3f689ea9f51
   • Microphysics git hash: e0fb64711aec4fe63208d2efb7cdbafbfb452b49

[zingale]

my experiementation.

Results look bad as shown above when using Castro 16.12 together with current BoxLib and Microphysics

Results look good when using the version from just 5 days earlier, af6370b, with current BoxLib, and older Microphysics (037b1ce). We need the older Microphysics to compile.

Good news is that we can use the latest BoxLib for all this testing -- it is not the culprit.

[zingale]

I can confirm that the badness that shows up at C-F interface around early Dec. occurs to this change:

commit 862ab80e25d884641557228a972f2e115d7604f6                                                                                                                                           
Author: Max Katz <maximilian.katz@stonybrook.edu>                                                                                                                                         
Date:   Fri Nov 25 17:56:39 2016 -0500                                                                                                                                                    

    clean_state now calls computeTemp   

If I run after that, it looks bad. If I manually revert that one-line change in the source after that point, it looks great again.

Additionally, fixing the bug of leaving this out of the other clean_state does not fix things.

[zingale]

Here's an easy way to confirm this:

• checkout the latest Castro
• compile in Castro/Exec/science/bwp-rad as:

  make DIM=2 -j 4 COMP=gnu USE_RAD=FALSE DEBUG=FALSE

• run as:

  mpiexec -n 4 ./Castro2d.gnu.MPI.ex inputs_2d

If you do this, you'll see the artifacts at C-F interfaces.

But... modify Castro.cpp and comment out the computeTemp lines in both clean_state routines, and it goes away

[zingale]

Some plots.(all put on the same scale)

1. current development:

2. current development but with computeTemp commented out in both clean_states:

3. current development, with computeTemp in clean_state, but with the call to reset_internal_energy in computeTemp commented out:

[zingale]

also note that running the code from 16.10 looks great (you need to copy the inputs, probin, and model file from development)

[zingale]

from Max:

I also discovered that in the current version of the code, the problem goes away if you set castro.dual_energy_eta2 = 1.0. This has the effect of never resetting the internal energy to be equal to (total - kinetic). I assume one does not need to be so extreme, but I didn't test intermediate values relative to the default (1.e-4).

[zingale]

closing for now, since this problem is not active at the moment