[FLASH-USERS] The problem of Negative Internal Energy in 3T MHD simulation with laser generated plasmas

Thu Apr 18 12:35:16 EDT 2019

Dear Klaus,
Thank you for your reply.
Maybe the initial gas density and temperature is too low in my simulation. When the laser irradiate the target, the self-generated magnetic field would be very large due to the great gradients of pressure and density and the low gas density. I'm trying to solve this problem by increasing the initial density and temperature.
I'm sorry for mixing two different runs output.
Best regards,
Wenyi

-----Original Message-----
From: Klaus Weide [mailto:klaus at flash.uchicago.edu] 
Sent: Thursday, April 18, 2019 5:17 PM
To: Huo Wenyi <Wenyi.Huo at eli-beams.eu>
Cc: flash-users at flash.uchicago.edu
Subject: Re: [FLASH-USERS] The problem of Negative Internal Energy in 3T MHD simulation with laser generated plasmas

On Wed, 17 Apr 2019, Huo Wenyi wrote:

> Dear all:
> 
> I am using FLASH to simulate the magnetohydrodynamics in laser 
> generated plasmas. However, I always encounter a problem of negative 
> internal energy both in FLASH 4.5 and FLASH4.6. Does anyone encounter 
> such a similar problem?  The error information in the Log file is as follows:

Dear Huo Wenyi,

Welcome to the club. :)

You are definitely not the only one encountering these kinds of errors.
Unfortunately, there is a variety of causes for problems that ultimately show up as "negative [or zero] internal energy". The details will depend on your specific simulation, and what goes on in different locations of it.

One thing to try early on when you encounter this, as an attempt to work around it, is making the time step smaller - usually by lowering the CFL factor.

The message you quote shows the coordinate location where the problem occurs (or where the underlying problem first becomes so severe that the simulation cannot continue), see "CELL X" / "CELL Y". Is there anything unusual or unphysical going on at that location, BEFORE the time step that fails? You may want to drop a plot file (or checkpoint) right before the error happens, to examine the state of the simulation more closely.

One thing I notice from your quoted message is that density seems rather low (DENS_OLD, DENS_NEW) at the problem cell. Whether 1.E-09 is actually low, maybe unphysically low, depends on your simulation.
For your simulation it is most likely unphysical. Maybe changing your initial condition can improve this. Maybe change the "smlrho" runtime parameter.

I have a suspicion that magnetic energy plays a large role in the energy balance of the region where the error manifests. You could check that, for example by comparing the size of the variable MAGP (magnetic pressure or magnetic energy density) with that dens*ener, dens*eint, dens*eele.

More information would be needed to analyze this further. (setup command, log file, initial conditions and other code changes, ...)

Klaus

> [ 04-16-2019  14:34:35.488 ] [hy_uhd_ragelike] ERROR DETECTED
> [ 04-16-2019  14:34:35.488 ]   Zero or negative advected specific internal energy detected
> [ 04-16-2019  14:34:35.488 ]   DENS_OLD =  1.0000904290291E-09
> [ 04-16-2019  14:34:35.488 ]   DENS_NEW =  1.0000983091349E-09
> [ 04-16-2019  14:34:35.488 ]   UTOT_NEW = -3.7386802822434E-01
> [ 04-16-2019  14:34:35.488 ]   UEXTRA = -1.7491864582091E+01
> [ 04-16-2019  14:34:35.488 ]     UELE_NEW = -3.7135596091566E-01
> [ 04-16-2019  14:34:35.488 ]     UION_NEW = -2.5120492887951E-03
> [ 04-16-2019  14:34:35.488 ]     URAD_NEW = -1.8019885718467E-08
> [ 04-16-2019  14:34:35.488 ]     EELE_VAR =  1.7001438966846E+10
> [ 04-16-2019  14:34:35.488 ]     EION_VAR =  1.1498940630502E+08
> [ 04-16-2019  14:34:35.488 ]     ERAD_VAR =  8.2498749422145E+02
> [ 04-16-2019  14:34:35.488 ]     EELE     = -3.7131945682109E+08
> [ 04-16-2019  14:34:35.488 ]     EION     = -2.5118023556785E+06
> [ 04-16-2019  14:34:35.488 ]     ERAD     = -1.8018114373230E+01
> [ 04-16-2019  14:34:35.488 ]     uele_adv  =  1.7002978536045E+01
> [ 04-16-2019  14:34:35.488 ]     uion_adv  =  1.1501719275908E-01
> [ 04-16-2019  14:34:35.488 ]     urad_adv  =  8.2506210304961E-07
> [ 04-16-2019  14:34:35.488 ]   PELE_VAR =  1.2145270532940E+00
> [ 04-16-2019  14:34:35.488 ]   PION_VAR =  7.6660475248193E-02
> [ 04-16-2019  14:34:35.488 ]   PRAD_VAR =  2.7502069901319E-07
> [ 04-16-2019  14:34:35.488 ]   PELE_ADV =  1.2145343502140E+00
> [ 04-16-2019  14:34:35.488 ]   PION_ADV =  7.6672066071296E-02
> [ 04-16-2019  14:34:35.488 ]   PRAD_ADV =  2.7502070101654E-07
> [ 04-16-2019  14:34:35.488 ]   TELE_VAR =  6.0996867323016E+02
> [ 04-16-2019  14:34:35.488 ]   TION_VAR =  3.6907447766733E+00
> [ 04-16-2019  14:34:35.489 ]   TRAD_VAR =  1.0219015193890E+02
> [ 04-16-2019  14:34:35.489 ]   CELL X =  3.3222656250000E-01
> [ 04-16-2019  14:34:35.489 ]   CELL Y =  6.9890625000000E-01
> [ 04-16-2019  14:34:35.489 ]   CELL Z =  0.0000000000000E+00
> [ 04-16-2019  14:34:35.489 ]   You might be able to get things to keep running by trying
> [ 04-16-2019  14:34:35.489 ]   more diffusive hydro options (reduce CFL, order, etc...)
> [ 04-16-2019  22:00:17.496 ] [hy_uhd_ragelike] Negative internal energies in 3T update
> [ 04-16-2019  22:00:17.496 ]   Falling back to using internal energy ratios instead of pressure ratios

It also seems that you have combined log file output from at least two different runs here (note time stamps), which have failed (or not) in different ways. It would better not to do this.

Klaus