[FLASH-USERS] ensuring div B = 0 when adjusting evolution

Fri Jun 9 06:24:53 EDT 2017

Hi All,

Not sure if this is relevant, but if it is related to problems of B field gradient across coarse/fine boundaries then it sounds at least superficially similar to a problem I had a while ago so I thought I would at least point it out in case there is a connection or possible clues for you (http://flash.uchicago.edu/pipermail/flash-users/2016-May/001957.html)

Unfortunately – I never got to the bottom of it and ended up tackling that particular problem with a different code using a stretched grid instead of AMR. I would however very much like to use FLASH for similar problems so I am watching this thread with great interest…

Cheers,

Jonathan

From: <flash-users-bounces at flash.uchicago.edu> on behalf of Dongwook Lee <dongwook at flash.uchicago.edu>
Date: Friday, 9 June 2017 at 00:05
To: "Slavin, Jonathan" <jslavin at cfa.harvard.edu>
Cc: flash-users <flash-users at flash.uchicago.edu>
Subject: Re: [FLASH-USERS] ensuring div B = 0 when adjusting evolution

Hi Jon,

Do you see large B fluctuations aligned with the fine-coarse block boundaries; and they get larger over time?

Just to add one quick suggestion: what Riemann solver you've been using? If HLLD, can you try to switch to HLLC or HLL and see if the fluctuations still persist?

Cheers,
Dongwook

On Fri, May 26, 2017 at 1:38 PM, Slavin, Jonathan <jslavin at cfa.harvard.edu<mailto:jslavin at cfa.harvard.edu>> wrote:
To answer Sean and Ernesto's questions:
I am using the USM solver and AMR.  I have now determined that div B is still 0 after the second explosion, which is not too surprising since, for this run, I have not changed the magnetic field and include div B cleaning (killdivb = .true.). So the problem is not with non-zero div B but with the large B fluctuations that are initiated. I noticed that there are small scale fluctuations in the region where the second explosion is initiated before the explosion, though the field is weak ~ 0.01 muG.  The fluctuations after the explosion go from ~ -1000 muG - +1000 muG.  I do expect amplification of B field fluctuations at the shock, but not to that extent.

The way I'm initiating the second explosion is (almost) the same way I initiate the first one - I set the pressure of parcels within a given radius to a value such that the sum of the energy in those parcels is equal to the value I want for the explosion (1.E51 ergs).  I set the density to a value so as to have the mass total to 8 solar masses.  So all the energy is thermal at first.  I'll see about calling the EOS unit, since I haven't done that.  Any additional info on how to do that would be appreciated.

Thanks,
Jon

On Fri, May 26, 2017 at 1:00 PM, <flash-users-request at flash.uchicago.edu<mailto:flash-users-request at flash.uchicago.edu>> wrote:
---------- Forwarded message ----------
From: ERNESTO ZURBRIGGEN <ezurbriggen at unc.edu.ar<mailto:ezurbriggen at unc.edu.ar>>
To: flash-users at flash.uchicago.edu<mailto:flash-users at flash.uchicago.edu>
Cc:
Bcc:
Date: Fri, 26 May 2017 10:56:45 -0300
Subject: Re: [FLASH-USERS] ensuring div B = 0 when adjusting evolution
Hi Jon!

Have you tried to set off a less intense second supernova explosion? Have you observed the same problems in that case? The second explotion might be much too intense.

On the other hand, how do you set the later explotion? I mean, applying the explotion, are you consistently modifying the thermodynamical variables? For example, if you instantaneously modify the density and the temperature, then you also should call the Eos unit to keep the consistence. I have experimented situations in which just modifying velocities and keeping the thermodynamics unaltered, I also had to call the Eos unit in order to maintain consistence

Some runtime parameter that might help being on are 'shockDetect' and 'shockLowerCFL' (this last one I think is just in realease 4.4).

Best!

--
Ernesto Zurbriggen

Instituto de Astronomía Teórica y Experimental (IATE).
Observatorio Astronómico de Córdoba (OAC), Universidad Nacional de Córdoba (UNC).
Teléfono: +54 0351 4331064-5, interno 222.
Córdoba, Argentina.

---------- Forwarded message ----------
From: "Sean M. Couch" <couch at pa.msu.edu<mailto:couch at pa.msu.edu>>
To: "Slavin, Jonathan" <jslavin at cfa.harvard.edu<mailto:jslavin at cfa.harvard.edu>>, flash-users <flash-users at flash.uchicago.edu<mailto:flash-users at flash.uchicago.edu>>
Cc:
Bcc:
Date: Fri, 26 May 2017 14:07:22 +0000
Subject: Re: [FLASH-USERS] ensuring div B = 0 when adjusting evolution
Hi Jon,

Can you give a little more info? Are you using the USM solver? Are you using AMR? Have you actually checked that divB>0 in the output data? A log file from a representative run would be useful.

In my experience, the USM solver in cylindrical R-Z coordinates with AMR can be….touchy. But it should work and maintain divB=0! (See, e.g., http://adsabs.harvard.edu/cgi-bin/nph-data_query?bibcode=2013ApJ...773..136J&link_type=EJOURNAL).

Cheers,
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<tel:(517)%20884-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 25, 2017 at 4:41:45 PM, Slavin, Jonathan (jslavin at cfa.harvard.edu<mailto:jslavin at cfa.harvard.edu>) wrote:
Hi all,

I'm running MHD simulations where I set off a second supernova explosion within a pre-existing remnant.  I'm using Simulation_adjustEvolution for this.  However, I'm running into a problem with the magnetic field just after initiating the second explosion.  I'm getting very large pixel-to-pixel variations in Bx and By at the edge of the new expanding blast wave.  I'm thinking that it could be because of non-zero div B in the region in which the explosion is generated. So my question is, does anyone have a suggestion for div B cleaning at the point that the explosion is started, i.e. within Simulation_adjustEvolution, to prevent the problems I'm having? I don't really expect the B field to be dynamically important inside the remnant (beta >> 1), so accuracy of the B field is probably not important there.  I should add that I'm doing these calculations in 2D cylindrical symmetry (R-Z).  Thanks in advance for any help.

Regards,
Jon

_______________________________________________
flash-users mailing list
flash-users at flash.uchicago.edu<mailto:flash-users at flash.uchicago.edu>
http://flash.uchicago.edu/mailman/listinfo/flash-users
--
________________________________________________________
Jonathan D. Slavin                 Harvard-Smithsonian CfA
jslavin at cfa.harvard.edu<mailto:jslavin at cfa.harvard.edu>       60 Garden Street, MS 83
phone: (617) 496-7981<tel:(617)%20496-7981>       Cambridge, MA 02138-1516
cell: (781) 363-0035<tel:(781)%20363-0035>             USA
________________________________________________________

--

=========================================
Dongwook Lee, Ph.D., Assistant Professor
Applied Mathematics and Statistics
University of California, Santa Cruz
Baskin Engineering, Room 353C
1156 High Street, Santa Cruz, CA 95064
https://users.soe.ucsc.edu/~dongwook/

This message is intended solely for the addressee and may contain confidential and/or legally privileged information. Any use, disclosure or reproduction without the sender’s explicit consent is unauthorised and may be unlawful. If you have received this message in error, please notify Northumbria University immediately and permanently delete it. Any views or opinions expressed in this message are solely those of the author and do not necessarily represent those of the University. The University cannot guarantee that this message or any attachment is virus free or has not been intercepted and/or amended.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20170609/17673211/attachment.htm>