Main menu


Questions on physics_buffer

8 posts / 0 new
Last post
Questions on physics_buffer

I would like to copy a physics_state and a physics_tend type before some physics happens and to restore it/part of it later.


What model version are you using?




I am running pure mpi, state_save and tend_save are defined at the module level

then in one routine I have:

nstep = get_nstep()
write(0, *) 'crm_save_state_tend: nstep: ', nstep
write(0, *) 'crm_save_state_tend: allocating tend_save'
call physics_tend_alloc(tend_save, pcols)
end if
call physics_tend_init(tend_save)
tend_save = tend

The output is:

crm_save_state_tend: nstep: 0
crm_save_state_tend: allocating tend_save
(shr_sys_abort) ERROR: physics_tend_alloc error: allocation error for tend%dtdt


I am suspecting the problem is when the second time it passes by to do another chunck of grid (and it still is the first step)

it complains that tend_save is already allocated ...




In the physics_types module there are subroutines physics_state_copy and physics_ptend_copy to make local copies of state and ptend objects.

You probably want to be working with a physics_ptend object and not a physics_tend object.  The ptend objects are what the individual parameterizations return to the driver layer.  The tend objects are updated with the information from a ptend object by physics_update.  There is no physics_tend_copy subroutine because we've not yet come across a need for one.




Thanks for the answer.

1, How about the subroutines named: pbuf_add_field, pbuf_get_field ?

It seems both two are used in a easy way in crm_physics.f90 (SPCAM) as following:

 call pbuf_add_field('CRM_U',     'global', dtype_r8, (/pcols,crm_nx, crm_ny, crm_nz/),                crm_u_idx)
call pbuf_get_field (pbuf, crm_u_idx,         crm_u).

It seems these variables are not assigned to all the chunks but still working.

2, And whats the different between "global" and "physpkg"? Is there any limitation about the size of fields put into the physics puffer?


Thank you, Brian. What I am doing is not the best practice.

Log in or register to post comments

Who's new

  • alessandro.delo...
  • zweina@...
  • yuan.liang@...
  • lian.xue@...
  • 353482168@...