[FLASH-USERS] Grid changed

[Klaus Weide]

On Tue, 17 Jan 2017, Seyit Hocuk wrote:

> Thanks Mark,
> 
> That will work.
> After my email, my current rough solution became to compare old vs. new total
> blocks. 

Seyit,

That is dangerous - old & new number of blocks may be the same after a 
refinement update, if the same number of blocks were deleted (by 
derefinement) as  have been created (by refinement) elsewhere in the 
domain.

> I may swith to your method if there is no better/more elegant way.

I am surprised that going from "Split" to "Unsplit" Driver has changed the 
behavior of 'grid_changed' for you - that was not an intended code change.
However, 'grid_changed' is a private variable owned by PARAMESH and there
should be no expectation of any specific behavior... This has come up 
before, you can probably locate some discussion by searching the 
flash-users mailing list archive for "grid_changed".

It seems that grid_changed is reset to 0 in some routines that are all
related to Poisson-solving. I suspect that the change in behavior you
observe is due to the fact that you are now using a different 
implementation of Driver_evolveFlash than before, with a different order
of calls (in particular, of your code in relation to any
Gravity_potentialListOfBlocks() calls).

Note also that the value grid_changed right after Grid_updateRefinement is 
exposed to Driver_evolveFlash as gridChanged and can be tested there.

> 
> call MPI_Allreduce(lnblocks, co_tot_blocks, 1, FLASH_INTEGER, MPI_SUM,
> MPI_COMM_WORLD, error) !>>> NOTE is MPI_COMM_WORLD or amr_mpi_meshComm better?

Better is amr_mpi_meshComm. It will be the same as MPI_COMM_WORLD if you 
are not using "mesh replication".

Klaus