<div dir="ltr">Thanks Klaus,<div><br></div><div>   I do intend to extend this into 2d, and possibly 3d, on large parallel machines, so the mesh replication is certainly of interest.    The reason I was concerned was that the mesh replication actually altered the simulation variables in my setup.  The deposition energy in the simulation is doubled when I set meshCopyCount =2.    The setup was modified from the LaserSlab example initially.  But when I run some of the example problems (LaserSlab, Sedov, Rad Blast Wave and few others) the .dat file is inaccurate, but the results of the simulation do not change in the way my setup does.   I'm not sure what I did in my setup, but I'm testing a few changes to see if I can resolve the issue.    </div><div><br></div><div>   I see some examples use solnData() to set the initial simulation variables.  Others use Grid_putPointData().  Is there a preferred method or issues with using one or the other than might be the issue?</div><div><br></div><div>Regards,</div><div>Pete</div><div><br></div><div>   </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 9, 2020 at 1:08 PM Klaus Weide <<a href="mailto:klaus@flash.uchicago.edu" target="_blank">klaus@flash.uchicago.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On Mon, 9 Mar 2020, Nelson, Peter wrote:<br>
<br>
> 2) meshCopyCount seems to multiply the internal energy initialized in the<br>
> Simulation_initBlock routine.  if I print the solnData at the end of<br>
> simulationInitBlock, everything looks fine, but when the simulation runs it<br>
> somehow ends up with the internal energy getting multiplied by<br>
> meshCopyCount.    Same issue on all three systems (with FLASH4.6.2<br>
> installs).  I checked multiple supplied test problems and they all present<br>
> the same problem.<br>
<br>
Peter,<br>
<br>
I wonder whether it makes sense for you to used mesh replication (i.e., <br>
meshCopyCount > 1) in the first place. If you just started using it in an <br>
attempt to work around a problem in your MPI installation, then it may not <br>
make sense anyway.<br>
<br>
Mesh replication was introduced in FLASH to deal with problems in large,<br>
highly parallel simulations with large memory and CPU time requirements.<br>
It is likely not so useful for a 1D configuration.<br>
<br>
Anyway, when you use mesh replications, most of the solution is <br>
represented redundantly multiple times (except for the radiation group <br>
energies), just as most of the computation is performed, redundantly, <br>
multiple times in parallel (except for the radiation transport).<br>
It seems likely that the version of IO_writeIntegralQuantities.F90<br>
that you are using, possibly the default implementation from the IO unit, <br>
simply is unaware that mesh replication is in effect, and is summing<br>
contributions to energy (and density, and other variables) over *all*<br>
replicated instances of the mesh, instead of just *one*.<br>
<br>
The solution may be as simple as replacing io_globalComm, io_globalMe<br>
with io_meshComm, io_meshMe, respectively, in <br>
IO_writeIntegralQuantities.F90, *and* making sure that only *one* instance <br>
of the mesh [which one?] actually performs the summation.<br>
<br>
I have not tried this, and do not know how this needs to be modified to <br>
actually have all the radiation group energies appear in the flash.dat <br>
file (if one is really using MGD for RadTrans with mesh replication). It <br>
is possible that people have written customized versions of <br>
IO_writeIntegralQuantities.F90 for specific simulations that deal with <br>
this properly.<br>
<br>
Klaus<br>
</blockquote></div>