<div dir="ltr"><div>Dear FLASH users,</div><div><br></div><div>I've encountered a new issue in setting up a magnetized inflow via modifying the included Torus problem.</div><div>As a recap, I modified the included Torus problem (FLASH4.5):</div><div>1) uniform density and temperature with zero velocity and zero magetic fields (Simulation_initBlock)</div><div>2) 3D cartesian geometry (flash.par and setup command)</div><div>3) include a magnetized inflow from the lower z-face of the domain with other boundary conditions = outflow (Grid_bcApplyToRegionSpecialized, flash.par)</div><div>4) turned off gravity (useGravity = .false. in flash.par)</div><div><br></div><div>However, when I include the gravitational acceleration from a Hernquist potential (that is: gpot = -GM / (r + r0)),</div><div>then the z-component of the magnetic field (which was previously zero for all time) obtains a dipolar structure even after just one evolutionary step</div><div>(see attached slice plot). Although the value of the field is very weak at that time, it grows to ~1 microGauss within 10 Myr which isn't a good sign.<br></div><div><br></div><div>All other variables (density, temperature, velx, vely, velz, magx, magy) look fine, so I'm at a loss as to why gravity should solely affect the z-component</div><div>of the magnetic field at the inflow boundary.</div><div><br></div><div>I would be very grateful for help in debugging this issue.<br></div><div><br></div><div>Best,<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">--------<div>Ryan</div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 2, 2019 at 8:17 PM Ryan Farber <<a href="mailto:rjfarber@umich.edu">rjfarber@umich.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"><div dir="ltr">Dear Flash users,<div><br></div><div>Sorry for the spam. Hopefully this will help someone in the future.</div><div><br></div><div>Setting BCs to outflow rather than periodic (with xl_boundary_type = "user") appears to have fixed the problem (initialization and one evolution step completes successfully).</div><div><br></div><div>Also, the reason I was seeing minval(unk(DENS_VAR,:,:,:, :)) = 0 even at the very start of mpi_amr_guardcell is because the last index of unk is blocks which includes values for all MAXBLOCKS, with unused block values set to zero. </div><div><br></div><div>I remedied that by checking minval(unk(DENS_VAR, :,:,:, 1)) and found the issue I was having with xl_boundary_type = "user" and other BCs set to periodic is because unk1 is set to zeros in mpi_amr_1blk_guardcell whereas that doesn't happen if the other BCs are set to outflow. </div><div><br></div><div>I should also mention that my write statements at the very start of Grid_bcApplyToRegionSpecialized were executed for mostly outflow BCs whereas they were not for mostly periodic BCs. </div><div><br></div><div>So, if someone does need to mix periodic with user BCs I suspect the issue is ultimately in mpi_amr_1blk_guardcell. </div><div><br></div><div>However, I don't plan on investigating further since outflow BCs are preferable for my problem to periodic.<br clear="all"><div><div dir="ltr" class="gmail-m_4137907770191418245gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div>Best,</div><div dir="ltr">--------<div>Ryan</div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 2, 2019 at 3:44 PM Ryan Farber <<a href="mailto:rjfarber@umich.edu" target="_blank">rjfarber@umich.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"><div dir="ltr">Dear all,<div><br></div><div>I have not fixed the issue of zero density values within Eos yet but would like to share the following update and would be very grateful for help in understanding why unk (in the physicaldata module) would have all zero values despite solnData receiving values in Simulation_initBlock.</div><div><br></div><div>First, I should mention that the error occurs in eos_idealGamma which is called by Eos -> Eos_wrapped -> Eos_guardCells -> Grid_fillGuardCells -> Grid_markRefineDerefine -> gr_expandDomain -> Grid_initDomain -> Driver_initFlash</div><div><br></div><div>At first, I found that the minimum value of density was zero at the end of Simulation_initBlock because the loop setting density did not include guard cells. So, I modified that (replaced blkLimits with blkLimitsGC for the loop start and stop values) and found that the minimum density was fine until after the call to amr_guardcells in Grid_fillGuardCells.</div><div><br></div><div>Within Grid_fillGuardCells, just before the call to amr_guardcells I found that minval(solnData(DENS_VAR,:,:,:) was the value I set for all (5) blocks. However, the very start of amr_guardcells (within mpi_amr_guardcells.F90) has minval(unk(DENS_VAR,:,:,:,:) = 0.0 (and also all zeros for all other variables).</div><div><br></div><div><br></div><div>Additionally, the end result of amr_guardcells is to set the density = -1.0 for the parent block while setting the density to zero for the leaf blocks. </div><div><br></div><div>This is undesirable yet I am not sure how to proceed. I'd be very grateful for any suggestions or ideas people may have.</div><div><br></div><div>Best<br clear="all"><div><div dir="ltr" class="gmail-m_4137907770191418245gmail-m_7942620074762894125gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">--------<div>Ryan Farber</div><div>PhD Candidate, University of Michigan</div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 2, 2019 at 1:12 PM Ryan Farber <<a href="mailto:rjfarber@umich.edu" target="_blank">rjfarber@umich.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"><div dir="ltr">Dear FLASH users,<div><br></div><div>TL;DR: Setting xl_boundary_type = "user", cells are filled with zero density although Grid_bcApplyToRegionSpecialized was not yet called. There is no such problem with all periodic BCs. If someone familiar with user BCs could mention which additional routines are executed that I might want to look into to debug this problem I'd very much appreciate it.</div><div><br></div><div>=========================================================</div><div><br></div><div>I am trying to modify the Torus problem included in FLASH4.5 to include a magnetized inflow from the lower x-boundary. </div><div><br></div><div>So, I modified flash.par to turn off gravity, comment out gr_prmp* variables, set geometry to cartesian, lrefine_min = 3, and set all BCs to periodic except xl_boundary_type = "user".</div><div><br></div><div>Additionally, I modified Simulation_initBlock so the domain is initially at a uniform density and temperature with zero velocity and zero magnetic field.</div><div><div dir="ltr" class="gmail-m_4137907770191418245gmail-m_7942620074762894125gmail-m_-7606397459238128042gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div>When I run the simulation with all BCs set to periodic, I receive many warning messages about the density being the value I set (modulo roundoff error) with a lot of output (possibly printing the entire density array?); however, it runs to completion fine and plots show the domain remained uniform (as to be expected).</div><div><br></div><div>However, when I set xl_boundary_type = "user" then the warning messages say minimum density is -1.0 and it crashes with:</div><div>





<p class="gmail-m_4137907770191418245gmail-m_7942620074762894125gmail-m_-7606397459238128042gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-m_4137907770191418245gmail-m_7942620074762894125gmail-m_-7606397459238128042gmail-s1" style="font-variant-ligatures:no-common-ligatures">ERROR After calling Eos, eosData(EOS_EINT) or eosData(EOS_DENS) are zero</span></p></div><div dir="ltr"><br></div><div>Compiling with -debug I receive a "floating invalid" error with traceback to eos_idealGamma.F90 with a line in which there is a division by density (which is zero, triggering the floating invalid error). However, I have write statements at the start of Grid_bcApplyToRegionSpecialized that are never executed suggesting that routine is not called yet.</div><div><br></div><div>I am seeking to eliminate this zero density issue; I'd be very grateful for any pointers those familiar with user BCs could point out.</div><div><br></div><div>Best,</div><div>--------</div><div dir="ltr"><div>Ryan Farber<br></div><div>PhD Candidate, University of Michigan</div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>