[Mesa-users] unintended consequences of not properly neutralizing namelist commands.

[Warrick Ball]

Hi Amber,

No problem!  Your report did prompt us to have a look at the special rate factor routine, which did have potential for confusion.  Specifically, that a failed dictionary-lookup quietly returns zero and continues the loop means that if a user didn't get a reaction name *exactly* right, that rate factor is unchanged and MESA quietly continues.

Future versions of MESA will avoid this by producing an error if the user provides an invalid reaction name.  So though the two "improper" examples you sent should work in current versions of MESA, they will stop working in the next release.  If you're experimenting with a selection of special rate factors and don't want to turn them all off with

     num_special_rate_factors = 0

then a particular special rate factor should be "nullified" by setting that factor to 1. e.g. if you're experimenting with two factors using

     num_special_rate_factors = 2

     reaction_for_special_factor(1) = 'r34_pp2'
     special_rate_factor(1) = 10

     reaction_for_special_factor(2) = 'r34_pp3'
     special_rate_factor(2) = 10

and want to briefly disable only `r34_pp2`, then set

     special_rate_factor(1) = 1

This will also work in the current version.

Cheers,
Warrick




___________

Warrick Ball
Postdoc, School of Physics and Astronomy
University of Birmingham, Edgbaston, Birmingham B15 2TT
W.H.Ball at bham.ac.uk
+44 (0)121 414 4552

On Tue, 13 Apr 2021, amberlauer at gmail.com wrote:

> Hi Warrick, I went back and went over all the files and discovered it was in fact user error, just not the one I thought. I was using diff to check if the history.data files were different, and that's how I claimed the runs were different. I forgot
> that I had added elapsed_time to the history file and that adds a column of values that will be different by definition. 
> 
> I take comfort in the fact that my original intuition was correct and MESA works the way I thought. Thanks for working through this with me.
> 
> =================================
> Dr. Amber Lauer-coles
> Postdoctoral Researcher
> Triangle Universities Nuclear Lab
> Duke University
> amber.lauer at tunl.duke.edu
> 
> 
> On Mon, Apr 12, 2021 at 6:47 PM amber lauer <amberlauer at gmail.com> wrote:
>       Hey Warrick, now I'm doubting myself and will run again to check. I'll report back.
> 
> =================================
> Dr. Amber Lauer-coles
> Postdoctoral Researcher
> Triangle Universities Nuclear Lab
> Duke University
> amber.lauer at tunl.duke.edu
> 
> 
> On Mon, Apr 12, 2021 at 4:47 AM Warrick Ball <W.H.Ball at bham.ac.uk> wrote:
>       Hi Amber,
>
>       > This is definitely a user issue and not code issue.
>
>       I'm not sure about that!  I'm surprised that your example "bad" inlist options led to unintended consequences, so I had a look at the block of code that sets the special rate factors.  This is most of the subroutine
>       `set_rate_factors` in `star/job/run_star_support.f90`:
>
>                 s% rate_factors(:) = 1
>                 if (s% job% num_special_rate_factors <= 0) return
>
>                 call get_net_reaction_table_ptr(s% net_handle, net_reaction_ptr, ierr)
>                 if (ierr /= 0) return
>
>                 do i=1,s% job% num_special_rate_factors
>                    if (len_trim(s% job% reaction_for_special_factor(i)) == 0) cycle
>                    ir = rates_reaction_id(s% job% reaction_for_special_factor(i))
>                    j = 0
>                    if (ir > 0) j = net_reaction_ptr(ir)
>                    if (j <= 0) cycle
>                    s% rate_factors(j) = s% job% special_rate_factor(i)
>                    write(*,2) 'set special rate factor for ' // &
>                          trim(s% job% reaction_for_special_factor(i)), &
>                          j, s% job% special_rate_factor(i)
>                 end do
>
>       In your first "bad" example (reaction name ' '), I would expect the `len_trim` line to return zero, so the loop will cycle, hit the iterator's upper limit and exit, leaving the rate factors untouched.
>
>       In your second "bad" example (reaction name 'placeholder'), I would expect the dict lookup function `rates_reaction_id` to fail, which should return zero.  Then `ir` is zero, so `j` isn't modified and, again, the loop will exit
>       without modifying the rate factors.
>
>       So your examples, as far as I can tell, should work.  That they don't may well indicate a bug, perhaps somewhere else in the code.
>
>       Could you send an inlist that reproduces the unintended consequences for your examples above?  I had a quick go at creating something myself but haven't got any "unintended" consequences.  Also, from the `write(*,2)` line in the
>       snippet above (and my own brief experiments), the terminal output should have lines like
>
>                         set special rate factor for rn14pg_aux          19    1.5000000000000000D+00
>                         set special rate factor for rn14pg_aux          19    1.5000000000000000D+00
>
>       near the start.  That's the output when I ran with
>
>            num_special_rate_factors = 1
>            reaction_for_special_factor(1) = 'rn14pg_aux'
>            special_rate_factor(1) = 1.5
>
>       What do you get with the "bad" examples?  So far, if I use the names ' ' or 'placeholder', I don't see those lines, presumably because the routine is exiting the way I expect it to, as described above, and therefore not modifying
>       the rates.
>
>       Cheers,
>       Warrick
> 
> 
>
>       ___________
>
>       Warrick Ball
>       Postdoc, School of Physics and Astronomy
>       University of Birmingham, Edgbaston, Birmingham B15 2TT
>       W.H.Ball at bham.ac.uk
>       +44 (0)121 414 4552
>
>       On Mon, 12 Apr 2021, mesa-users at lists.mesastar.org wrote:
>
>       > I want to report that things can go wrong if you don't properly nullify commands. Take for example a set of commands used to change reaction rates by a factor. One might use the following
>       >
>       > >num_special_rate_factors = 1
>       > >reaction_for_special_factor(1)='reaction1'
>       > >special_rate_factor(1) = 2
>       >
>       > The proper way to cancel these commands is to either 
>       > 1) comment them out with !
>       > 2) set num_special_rate_factors=0 (and possibly, leave reaction_name blank)
>       > or 3) set special_rate_factor(:)=1.
>       >
>       > The following are not the proper ways, and will lead to unintended consequences
>       >
>       > num_special_rate_factors = 1
>       > reaction_for_special_factor(1)=' '
>       > special_rate_factor(1) = 10
>       >
>       > or
>       >
>       > num_special_rate_factors = 1
>       > reaction_for_special_factor(1)='placeholder'
>       > special_rate_factor(1) = 10
>       >
>       > Please learn from my experience and save yourself some time and confusion. This is definitely a user issue and not code issue.
>       >
>       > =================================
>       > Dr. Amber Lauer-coles
>       > Postdoctoral Researcher
>       > Triangle Universities Nuclear Lab
>       > Duke University
>       > amber.lauer at tunl.duke.edu
>       >
>       >
> 
> 
>