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

[amber lauer]

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 <amber.lauer at 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 <amber.lauer at 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
>> >
>> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20210413/e8043109/attachment.htm>