[FLASH-USERS] Magnetized Inflow: Torus Problem

[Ryan Farber]

Dear FLASH users,

I've encountered a new issue in setting up a magnetized inflow via
modifying the included Torus problem.
As a recap, I modified the included Torus problem (FLASH4.5):
1) uniform density and temperature with zero velocity and zero magetic
fields (Simulation_initBlock)
2) 3D cartesian geometry (flash.par and setup command)
3) include a magnetized inflow from the lower z-face of the domain with
other boundary conditions = outflow (Grid_bcApplyToRegionSpecialized,
flash.par)
4) turned off gravity (useGravity = .false. in flash.par)

However, when I include the gravitational acceleration from a Hernquist
potential (that is: gpot = -GM / (r + r0)),
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
(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.

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
of the magnetic field at the inflow boundary.

I would be very grateful for help in debugging this issue.

Best,
--------
Ryan


On Sat, Feb 2, 2019 at 8:17 PM Ryan Farber <rjfarber at umich.edu> wrote:

> Dear Flash users,
>
> Sorry for the spam. Hopefully this will help someone in the future.
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> So, if someone does need to mix periodic with user BCs I suspect the issue
> is ultimately in mpi_amr_1blk_guardcell.
>
> However, I don't plan on investigating further since outflow BCs are
> preferable for my problem to periodic.
>
> Best,
> --------
> Ryan
>
>
> On Sat, Feb 2, 2019 at 3:44 PM Ryan Farber <rjfarber at umich.edu> wrote:
>
>> Dear all,
>>
>> 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.
>>
>> 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
>>
>> 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.
>>
>> 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).
>>
>>
>> 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.
>>
>> This is undesirable yet I am not sure how to proceed. I'd be very
>> grateful for any suggestions or ideas people may have.
>>
>> Best
>> --------
>> Ryan Farber
>> PhD Candidate, University of Michigan
>>
>>
>> On Sat, Feb 2, 2019 at 1:12 PM Ryan Farber <rjfarber at umich.edu> wrote:
>>
>>> Dear FLASH users,
>>>
>>> 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.
>>>
>>> =========================================================
>>>
>>> I am trying to modify the Torus problem included in FLASH4.5 to include
>>> a magnetized inflow from the lower x-boundary.
>>>
>>> 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".
>>>
>>> Additionally, I modified Simulation_initBlock so the domain is initially
>>> at a uniform density and temperature with zero velocity and zero magnetic
>>> field.
>>>
>>> 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).
>>>
>>> However, when I set xl_boundary_type = "user" then the warning messages
>>> say minimum density is -1.0 and it crashes with:
>>>
>>> ERROR After calling Eos, eosData(EOS_EINT) or eosData(EOS_DENS) are zero
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Best,
>>> --------
>>> Ryan Farber
>>> PhD Candidate, University of Michigan
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20190207/6036750d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: torus_inflow_mhd_3d_hdf5_chk_0001_Slice_x_magz.png
Type: image/png
Size: 37579 bytes
Desc: not available
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20190207/6036750d/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: torus_inflow_mhd_3d.log
Type: text/x-log
Size: 42675 bytes
Desc: not available
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20190207/6036750d/attachment-0001.bin>