[FLASH-USERS] Problems with set_parm_in_context

[Paul Goodall]

Hi Anshu,

Thanks for the reply, it's very instructive.

I figured out a solution a few days ago, which involved adding a subroutine call to my set_parameters subroutine, inside init_(my source term module) upon 'restart' being .true.
Everything now works as expected.

cheers,

Paul Goodall
========================
Astrophysics D.Phil Student
University of Oxford.
========================
Denys Wilkinson Building
Keble Road
Oxford
OX1 3RH
+44 (0)1865-2-83011
http://astroweb1.physics.ox.ac.uk/~Goodall/
========================

On 25 Jan 2010, at 21:37, Anshu Dubey wrote:

> Paul,
> 
> It has been a while since I have looked at FLASH2, so I may be wrong.
> However, looking at the source code now, I see no evidence that
> "mark_grid_refinement" is called from the default implementation of
> init_from_checkpoint. It is called from "evolve", and when you use
> "init_from_scratch", then there are calls to mesh_refine_derefine. I
> do know more about what we do in FLASH 3, and since most of the logic
> is similar, I am sure that FLASH 2 would be doing similar work at
> initialization.
> 
> When you start from scratch, there is a process of refinement in a
> loop to create the initial grid. There is no immediate need to refine
> when you start from checkpoint. We do use update_refinement call, but
> that is just to redistribute the blocks, there is no actual refinement
> done. The code in FLASH 2 looks like it actually carries out the
> distribution of blocks explicitly rather than handing control back to
> paramesh.
> 
> Again, I could be wrong about all of this from being out of touch with
> FLASH 2, but I do recommend that you make sure that
> "mark_grid_refinement" is actually called from restart.
> 
> Best,
> Anshu
> 
> On Thu, Jan 21, 2010 at 12:45 PM, Paul Goodall <ptg at astro.ox.ac.uk> wrote:
>> Dear Flash-users,
>> 
>> I don't think this qualifies as a bug, more likely just something I've missed out.
>> 
>> I'm using FLASH2.5 (haven't yet had the the chance to upgrade) and having really weird problems with saving parameters to the database.
>> 
>> In the mark_grid_refinement.F90 subroutine of my 'problem' setups directory, I calculate various quantities which are essential later on in the simulation, and save them to the database using:
>> 
>> call set_parm_in_context(global_parm_context, 'parmname', parmval)
>> 
>> (N.B I don't use 'add_parm_to_context' because the params in question are already initialised in Config)
>> 
>> These values are calculated and saved during the IF(firstcall) loop.
>> This is the bit were things become strange...
>> 
>> If I do a new run (i.e. restart = .false. in flash.par) then everything works brilliantly and all the calculated quantities are saved to the database for later use.
>> 
>> However, if I restart from a checkpoint, only *some* of the calculated quantities are saved to the database in the above way.  (i.e. when I call the parms later on in the source_terms/, some of them have the correct saved value, and some of them have reverted to the default value given in Config).  I know that the mark_grid_refinement.F90 is still called during a restart because I get it to print values to the screen/output files in both new starts and restarts such as:
>> 
>> call get_parm_from_context(global_parm_context, 'parmname', parmval)
>> print *,"Initial value: ", parmval
>> (** some calculation involving parmval **)
>> print *,"New value1: ", parmval
>> call set_parm_in_context(global_parm_context, 'parmname', parmval)
>> call get_parm_from_context(global_parm_context, 'parmname', parmval)
>> print *,"New value2: ", parmval
>> 
>> Where "New value1" and "New value2" being the same should surely indicate that the save to the database was successful? (I know that the above example is a bit dramatic, but its what I've resorted to to try and locate the problem).
>> 
>> Two things about this are strange to me:
>> 1) Why does this differ between a new start and a restart?
>> 2) Why are some params saved to the database, and others not, when they each have the same type (e.g REAL).
>> 
>> Any help with this (or if anyone has experience similar), would be really appreciated,
>> 
>> cheers,
>> 
>> Paul Goodall
>> ========================
>> Astrophysics D.Phil Student
>> University of Oxford.
>> ========================
>> Denys Wilkinson Building
>> Keble Road
>> Oxford
>> OX1 3RH
>> +44 (0)1865-2-83011
>> http://astroweb1.physics.ox.ac.uk/~Goodall/
>> ========================
>> 
>>