[FLASH-USERS] MHD (8wave & USM): Refinement region boundaries - spurious waves when B field is oblique to jumps in refinement.

Jonathan Thurgood jonathan.thurgood at northumbria.ac.uk
Thu May 12 07:11:33 EDT 2016


Dear Sean and John,

Thanks for your quick replies!

In the runs which produced the figures I sent across yesterday I had used these settings

E_modification = .true.
E_upwind = .false.
energy_fix = .true.
prol_method = “balsara_prol”

with  the Roe solver and  “order = 2 “ run time parameter.

I’ve since played with these settings and the choice of Riemann solver but unfortunately it looks like this particular artefact might be somewhat different to those seen in Sean’s loop advection test since it seems to be resilient to these changes.

Specifically, I’ve since tried the following


1)      Enable E_upwind whilst retaining other settings as above.
There is no appreciable difference.


2)      Changing the prol_method.

This makes no difference as far as I can tell (not even a slight change in the current amplitudes). I wondered if that in of itself was not strange?

Is it possible that the that special prolongation is only being applied when a block is refined to a lower level, but not when blocks of different levels of refinement compute guard cell data, but rather only some simple interpolation?


3)      Changing the Riemann solver from Roe to Hybrid to HLLD (reading the manual, Table 14.9 pg 219 makes it sound like these are the only options for USM?)

There are some slight quantitative differences but overall this doesn’t seem to help remove this particular artefact.


4)      Changed the runtime parameter “order” from 1,2,3,5 for Roe, Hybrid, and HLLD.

Orders > 2 showed only slight quantitative differences, with no real effect to supress the artefact.

Interestingly, order = 1 does change something.

For the Roe solver I’ve found that the current artefacts are reduced to singular points in the ‘corners’ of order 1e-15 , but this doesn’t resolve the problem altogether in that there are still artefacts in the flow fields at the refinement region boundaries (i.e., setting it to 1 seems to not compute bad current, but still sets up the flow fields associated with this artefact).

Order =1 for Hybrid and HLLD introduced new class of artefact associated with high eint and v at different locations, and crashed very quickly, “computed dt not positive”.


5)      I’ve checked that this occurs in both ideal MHD and with fairly large resistivity (1e-3). There is some quantitative change due to the diffusion but overall you still get this wave-launching from the corners.


I did wonder if it might be worth changing NGUARD (thus, how many cells the coarse side of the boundary needs to be interpolated into) but for the life of me I couldn’t figure out where you actually change this in the code (is it a setup argument? Flash.par didn’t seem to accept it). Can someone please let me know how to do this?

Thanks,

Jonathan

From: Sean Couch [mailto:smc at flash.uchicago.edu]
Sent: 11 May 2016 14:36
To: John ZuHone
Cc: Jonathan Thurgood; flash-users at flash.uchicago.edu
Subject: Re: [FLASH-USERS] MHD (8wave & USM): Refinement region boundaries - spurious waves when B field is oblique to jumps in refinement.

Good point, John!

I was using 5th-order WENOZ with HLLD.  There is a sort of odd-even-like artifact that can crop up in HLLD.  I’ve found a little bit of magnetic resistivity goes a long way toward fixing that.  I put together a quick gif<https://nagini.pa.msu.edu/index.php/s/JpBSEYEOzc4XZT9> of the magnetic pressure from the field loop test I did demonstrating the artifacts I saw and how they depend on the E-field construction parameters/Riemann solver/resistivity.

Sean

On May 11, 2016, at 8:58 AM, John ZuHone <jzuhone at space.mit.edu<mailto:jzuhone at space.mit.edu>> wrote:

It may also be relevant to know what hydro reconstruction method is being used in the case of USM (for both Sean and Jonathan?). There are known problems of this sort when using HLLD, for example.
On May 11, 2016, at 8:56 AM, Sean Couch <smc at flash.uchicago.edu<mailto:smc at flash.uchicago.edu>> wrote:

Hi Jonathan,

I’ve seen similar, though not identical, artifacts at refinement boundaries with USM using similar nested AMR grids in the context of stellar core collapse.  I was also able to reproduce artifacts using a simple field loop advection test that traverses a fixed jump in refinement.  What I found helped or, in the latter case, completely cleared it up was the following settings:

E_modification  = .true.           # High order algorithm for E-field construction
E_upwind         = .true.            # upwinding for E-field construction
energyFix         = .true.           # Update magnetic energy using staggered B-fields
prolMethod       = “injection_prol" # Prolongation method (injecton_prol, balsara_prol)

I think the last setting in particular is relevant here.  This is the method of prolongation in the guardcells at refinement boundaries.  What option are you currently using?  Injection is the default.  You may try switching the prolMethod and see if that changes anything.

I’m interested to here if any of this as an effect on what you’re seeing!

Sean


----------------------------------------------------------------------------------------------------------
Sean M. Couch
Assistant Professor
Department of Physics and Astronomy
Department of Computational Mathematics, Science, and Engineering
National Superconducting Cyclotron Laboratory/Facility for Rare Isotope Beams
Michigan State University
567 Wilson Rd, 3250 BPS
East Lansing, MI  48824
(517) 884-5035    ——    couch at pa.msu.edu<mailto:couch at pa.msu.edu>    ——    www.pa.msu.edu/~couch<http://www.pa.msu.edu/~couch>




On May 11, 2016, at 7:55 AM, Jonathan Thurgood <jonathan.thurgood at northumbria.ac.uk<mailto:jonathan.thurgood at northumbria.ac.uk>> wrote:

Dear All,

I was hoping someone might be able help me to overcome a seemingly serious problem which looks like it might prohibit me from migrating my current research project to FLASH.

SETUP DESCRIPTION:

The test setup is a linear, 2D magnetic null point:

B=[x,-y]   .

This is a cylindrically symmetric structure where the magnetic field strength linearly increases with radius. It is in force balance between magnetic tension and magnetic pressure and is known to be a stable equilibrium. All other parameters are taken as constants.  I essentially want to study implosions guided into this structure, so have implemented a ‘fixed’ multi-resolution mesh whereby the highest levels of refinement are clustered towards B=0 at the origin, e.g.:

https://jonathanthurgood.files.wordpress.com/2016/05/fig_fieldlines.png   (2d null point, field line structure)

https://jonathanthurgood.files.wordpress.com/2016/05/nullpoint_modb.png  (2d null point, modB profile and multi-resolution grid overlaid)

https://jonathanthurgood.files.wordpress.com/2016/05/grid_structure.png (grid structure)

I have implemented this by adding the following lines to Grid_markRefineDerefine.F90, after line 131 but before line 135 (without any other modification).

!  call Grid_markRefineSpecialized
  gmrs_size = 4
  gmrs_spec = (/ 0.0, 0.0, 0.0, 0.01 /)
  call Grid_markRefineSpecialized(INRADIUS, gmrs_size, gmrs_spec, lrefine_max)

I have turned off adaptive refinement by not specifying any refine_vars in flash.par . This is because I am worried about prolongation of  a B=0 containing cell causing issues, so would prefer to set the equilibrium field directly in the initial condition to ensure only one cell contains the null point itself.  Please note also that I am worried that  it is possible that the problem I am about to describe will be manifest in many other setups / applications with actual adaptive refinement also, but would be harder to spot.

PROBLEM DESCRIPTION / FIGURES:

If I then run the code to test the stability of the equilibrium (ie., no perturbations), the following current pattern quickly builds up at the boundaries of each refinement level. This then launches inward-propagating waves towards the origin/null point, at large enough amplitudes to interfere with the solution.

https://jonathanthurgood.files.wordpress.com/2016/05/current_usm_monotonic_order2.gif (CurZ, USM, monotonic, interpolation order 2)

I believe this problem is to do with the guard cell filling by interpolation on the refinement boundary  calculating an inappropriate field value which specifies a bogus current and launches waves driven by this erroneous imbalance of Lorentz force. This seems to be particularly bad in the corners here where the field strength is  increasing obliquely  to the cell faces, and so we have the impression of wave fronts emanating predominantly from the corners of the refinement boundaries.

Changing the monotonic interpolation order for guard cell filling, or switching to 8 wave with PARAMESH’s native interpolation, unfortunately does not fix this, but does change the shape and size of the artefacts as follows

https://jonathanthurgood.files.wordpress.com/2016/05/current_usm_monotonic_order0.gif (curz, USM, monotonic, interpolation order 0)
https://jonathanthurgood.files.wordpress.com/2016/05/current_usm_monotonic_order1.gif (curz, USM, monotonic, interpolation order 1)
https://jonathanthurgood.files.wordpress.com/2016/05/current_usm_monotonic_order2.gif (curz, USM, monotonic, interpolation order 2)
https://jonathanthurgood.files.wordpress.com/2016/05/current_8wave_native.gif  (curz, 8wave,native)

It is also interesting to note that I have in the past encountered a similar qualitative current build up / wave launching from the external/physical boundary if I use, say, outflow boundary conditions (or any other default) at the null, rather than my user defined condition which explicitly sets the field in the boundary.

https://jonathanthurgood.files.wordpress.com/2016/05/current_uniformgrid_defaultbc.gif  (curz, USM, outflow boundary + uniform)
https://jonathanthurgood.files.wordpress.com/2016/05/current_uniformgrid_userbc.gif (curz, USM, user defined boundary + uniform grid)
(note, by uniform grid I mean that these runs just set minimum and maximum refinement level to be the same, rather than switching to UG  mode properly)

You can see that any current for the correct BC is just numerical noise (note the magnitude), whereas the default boundary conditions give similar behaviour to that noticed at the refinement boundaries. I think this supports the idea that field is not correctly calculated at the boundaries of refinement (in the case of using outflow boundary at a null, field is incorrectly specified by the BC, in the case of refinement region boundaries, field is incorrectly specified by interpolation.)

OTHER SETUPS THAT SEEM TO HAVE THE SAME PROBELM

I can also reproduce the problem in another geometry suggesting that it isn’t specific or unique my 2D null point.

For example, I’ve tried the one dimensional field used in the Taylor problem and other reconnection studies.  Here,  if

B = [0,x]    + pressure chosen to maintain force balance

https://jonathanthurgood.files.wordpress.com/2016/05/taylor_problem_modb.png

                (see also http://adsabs.harvard.edu/abs/2003PhPl...10.4284F , which considered this problem with an early version of FLASH)

is considered with the same sort of static, multi-level grid I used at the null no such problems are initially encountered.

However, if one rotates everything by  45degrees so that the gradients in magnetic field are now oblique to the Cartesian grid, e.g.,

https://jonathanthurgood.files.wordpress.com/2016/05/taylor_problem_rotated_modb.png

similar artefacts to those described above for the null point can be clearly seen at the refinement boundaries.

Although I think I have the gist of why this is happening, I’m not sure about how to narrow it down further or begin to correct it.  Any advice on any aspect of the above, how to narrow this down further, possible solutions or general advice would be very much appreciated – I am very stuck!

Thanks for reading.

Best regards,

Jonathan



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20160512/3b5cab30/attachment.htm>


More information about the flash-users mailing list