[FLASH-USERS] Unsplit Hydro Solvers: Why and When?

Thu Feb 16 09:01:44 EST 2012

Hi Nathan,

It is true that transOrder=4 was released in the previous FLASH release,
and I took it out
from FLASH4-beta from the official release. One major reason I did this
was because
I have not yet found strong mathematical explanation how/why
transOrder=2,3, & 4 work.

I see that there have been some inquiries about using transOrder recently
for the
unsplit hydro/MHD solvers. In brief, here is what I should say:

* transOrder = 1 (good)
* transOrder = 2 (no good at all and not recommended to use)
* transOrder = 3 (magically works ok)
* transOrder = 4 (a combination of trasnOrder=1 and 3, and works better
than transOrder=3 sometimes)

Now here is some background story on transOrder:

I should say that transOrder=1 is the only one that has theoretical
explanation on stability
when integrated to solve 2D and 3D problems (it doesn't apply in 1D at all).
Using Fourier stability analysis, you can actually show that transOrder=2,
3, and 4 would not work for 3D. But transOrder=3 (or 4) somehow magically
works for some 3D problems, which I am not sure how to explain the
behavior.

In general most of the 2D problems will not need other than using
transOrder=1 as this will
give you good enough numerical stability. However, in 3D, transOrder=3 has
shown that
sometimes it adds more numerical stability (but without any theoretical
proof as far I understand!).

It is fair to say that transOrder=3 is only experimental and does not have
strong theoretical proof
how/why it should work better than transOrder=1. Therefore, transOrder=3
(or 4) still should remain as a research problem to me. For this reason, I
decided to take out transOrder=4 from the FLASH4-beta release.

For those who are FLASH4-beta users, please always use use_3dFullCTU =
.true. for 3D simulations with transOrder=1. With this combination, you
can use CFL~1 for 3D simulations. If use_3dFullCTU=.false. and
transOrder=1, then the theoretical CFL limit is bounded by 0.5.

IF you want to explore transOrder=3 (or 4 in previous versions), then I
recommend to use use_3dFullCTU=.false. along with CFL~0.5 for 3D.
Experimentally though, it seems that you can also increase CFL to 0.7 or
0.8, but officially, I don't want to recommend to use transOrder bigger
than 1.

Sorry for the confusion with using transOrder. I hope to come up with some
better mathematical explanation in near future.

Best,
Dongwook

=========================================
Dongwook Lee, Ph.D., Research Scientist
FLASH Center for Computational Science
University of Chicago
5747 S. Ellis Ave., Room 319
(773) 834-6830

> Hi all,
>
> Apologies for reviving an old thread, but I've been trying to get an
> unsplit MHD simulation running stably and I'm a bit confused by the
> suggestion to set transOrder = 4 in the previous message.
>
> The users guide only describes transOrder = 1, 2, and 3.  Can anyone
> describe what setting transOrder = 4 does?  Is there a reason why it isn't
> described in the users guide?
>
> Thanks for your help!
>
> -Nathan
>
>
> On Feb 13, 2012, at 2:51 AM, Seyit Hocuk wrote:
>
>> Hi,
>>
>> I use:
>>
>> order=3
>> transorder=4
>> rimannsolver=HLLD
>> slopelimiter=mc
>> eosforrieman=.true.
>>
>> Default for the rest
>>
>> I use order=3, because I want similar results with the simulations I did
>> with PPM.
>> TransOrder seems less important in my runs. I've played around with
>> that, but I don't think it's a critical parameter. TrOr=3 seemd to
>> produce less artifacts. As I understand, it's kind of averaging method,
>> like 'A-B' or '4A-3B-C' or '6A-3B-C-2D' or minmod('6A-3B-C-2D','A-B').
>> I think the Riemannsolver is quite important. 'Roe' never worked for me.
>> I've seen several papers where they say that 'HLLD' is one of the best,
>> so I use that one as well. Slopelimiter was a suggestion by Dongwook.
>>
>>
>> On 02/12/2012 04:27 PM, Massimo Gaspari wrote:
>>> Hi guys,
>>>
>>> I am glad that you share my interest on such an important topic, i.e.
>>> pros and cons of the unsplit hydro solver.
>>>
>>> Seyit:
>>> The workshop would be really interesting, but unfortunately I am
>>> unavailable for that date.
>>> When you say more diffusive ... which order/riemann/slope are you
>>> using? (and why?)
>>> In theory I should expect the unsplit solver to produce *less*
>>> artifacts compared to the split formulation
>>> (otherwise why bothering with a more complex scheme?).
>>>
>>> Tomek:
>>> Can you elaborate more on the "artifacts linked only to PPM"... this is
>>> kind of new for me (any reference?).
>>> I totally agree for the database of the verification tests, in
>>> particular comparing all the options of the unsplit module.
>>>
>>> Paul/Sean:
>>> The "FLASH knowledge base" seems a great idea.
>>> I do not totally agree about "in general they depend on the flow
>>> problem". I think that some kind
>>> of quality must be *independent* of the specific problem solved,
>>> leading to a solver better than another, also in general.
>>> Evidently some detail will be different, but I think we must find one
>>> (or more) scale to properly evaluate them.
>>>
>>> Dongwook:
>>> A verification paper would be really great, certainly more than the
>>> method paper, at least for the community.
>>> In particular the split vs unsplit comparison, testing different
>>> options.
>>> I totally agree with you that providing in advance a summary document
>>> with the *when & why*
>>> is really necessary. Can't wait to read that.
>>> I think in fact that only the FLASH developers of the unsplit module
>>> really know the behaviour of all the solvers/options
>>> and perhaps they have already a scale of preferences.
>>> In the meantime, what is *your* best hydro setup?
>>> Dongwook, what do you suggest to normally avoid?
>>>
>>> All:
>>> Thanks again for all your positive interest. On the other hand, may you
>>> kindly provide some specific example of your current unsplit setup?
>>> For instance:
>>> order=
>>> transOrder=
>>> RiemannSolver=
>>> ...
>>> 2 lines of explanation (e.g., seems more stable... seems more
>>> precise... less artifacts... I don't know, I like it!)
>>>
>>> Sadly, I am just starting to test the module, so I do not have much
>>> experience to share, aside that I've found this setup to be rather
>>> stable:
>>> order=3
>>> transOrder=2
>>> RiemannSolver=Roe
>>>
>>> TransOrder seems to be a critical switch in order to loose/gain
>>> stability. It is strange that with transOrder 1 crashes more than 2....
>>> but I need further tests.
>>> I am particularly interested in hydro simulations with multiphase gas
>>> in it (i.e., very dense and cold clumps inside hot and diffuse
>>> regions). Hope you have some experience in that direction. Strong
>>> gradients in density (and temp) usually make the code suddenly
>>> unstable. Any hint?
>>>
>>>
>>> Until next time,
>>>
>>>
>>>      Max
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> > Subject: Re: [FLASH-USERS] Unsplit Hydro Solvers: Why and When?
>>> > From: smc at flash.uchicago.edu
>>> > Date: Fri, 10 Feb 2012 16:22:07 -0600
>>> > CC: dongwook at flash.uchicago.edu; flash-users at flash.uchicago.edu;
>>> gaspmax at hotmail.com
>>> > To: pmricker at illinois.edu
>>> >
>>> > Paul,
>>> >
>>> > I love this idea. One word: FLASHBook. Unfortunately, that domain
>>> name is already occupied (and for something far less unsavory than I
>>> would have guessed). But we can work around that.
>>> >
>>> > Sean
>>> >
>>> > On Feb 10, 2012, at 2:00 PM, Paul M. Ricker wrote:
>>> >
>>> > > Dongwook,
>>> > >
>>> > > I'd like to add my support for something like what Massimo is
>>> requesting. The answers to his questions can be obtained from
>>> textbooks and the applied math literature, or informally from
>>> experienced algorithm developers, but in general they depend on the
>>> flow problem being solved. Documenting a group of test problems
>>> that demonstrate the pros and cons of the different switches would
>>> therefore be very useful. Perhaps the most feasible way to obtain
>>> this end, given limited resources, would be to create an online
>>> space of some type to allow users to submit this kind of
>>> information from their own experience. A FLASH Knowledge Base, if
>>> you will.
>>> > >
>>> > > Paul
>>> > >
>>> > >
>>> > >
>>> > > On 02/10/2012 01:20 PM, dongwook at flash.uchicago.edu wrote:
>>> > >> Dear Massimo,
>>> > >>
>>> > >> This is a really good case I can provide more useful information
>>> on the
>>> > >> unsplit hydro/MHD solvers.
>>> > >> I understand that, ultimately, it will be ideal to have a couple
>>> of useful
>>> > >> reference papers including at least:
>>> > >>
>>> > >> (a) a method paper, and
>>> > >> (b) a verification paper along with comparisons with other methods
>>> > >> (e.g., split vs unsplit; FLASH vs other codes)
>>> > >>
>>> > >> And unfortunately, these papers are in preparation and one of my
>>> todo list
>>> > >> in a near future.
>>> > >>
>>> > >> In the meantime, I think it will be a good idea for FLASH users
>>> that I
>>> > >> provide a summary document that describe several key
>>> features/usages
>>> > >> (e.g., answering when& why) in more detail (that what's done in
>>> the FLASH
>>> > >> users guide) and make that available to community.
>>> > >>
>>> > >> I will think about coming up with an idea how to provide such an
>>> useful
>>> > >> information in order to help users to use the FLASH's unsplit
>>> hydro/MHD
>>> > >> solvers for their research.
>>> > >>
>>> > >> Thank you for your interest in using the FLASH's unsplit solvers!
>>> > >>
>>> > >> Best,
>>> > >> Dongwook
>>> > >>
>>> > >> =========================================
>>> > >> Dongwook Lee, Ph.D., Research Scientist
>>> > >> FLASH Center for Computational Science
>>> > >> University of Chicago
>>> > >> 5747 S. Ellis Ave., Room 319
>>> > >> (773) 834-6830
>>> > >>
>>> > >>>
>>> > >>> Dear FLASH users/developers,
>>> > >>> I write this email in order to open a discussion on the unsplit
>>> hydro
>>> > >>> solver.A preamble.I have mostly used the basic split PPM module
>>> and I
>>> > >>> think it works pretty well.The only real "issue" is the
>>> splitting, which
>>> > >>> complicates the implementation of several physical
>>> modules.Therefore, I am
>>> > >>> right now testing the unsplit module (FLASH 4b).However... there
>>> are
>>> > >>> endless options! This is certainly a good thing. On the other
>>> hand, it is
>>> > >>> pretty daunting to test every single option/solver, plus several
>>> different
>>> > >>> combinations, even for a single problem.
>>> > >>> I am thus wondering if you (developers and users) may kindly
>>> provide more
>>> > >>> comments/experiences on the methods used in the unsplit solver. I
>>> don't
>>> > >>> want to know how the solver is written (I have Toro's book for
>>> that), but
>>> > >>> *when* and *why* we have to use a particular solver/option, and
>>> *which are
>>> > >>> the pros and cons/risks*?
>>> > >>> For instance, ...1) Using PPM (order=3) over Godunov (order=1) is
>>> pretty
>>> > >>> trivial, but why and when using MUSCL (order=2) over PPM?
>>> > >>> 2) I also do not understand the default value of several
>>> options...
>>> > >>> shouldn't be the default value the best (in theory) option? If so
>>> why
>>> > >>> transOrder=1? transOrder=2 seems to me a more appropriate choice,
>>> in
>>> > >>> general.When do you use transOrder=3? The same can be said for
>>> the half
>>> > >>> gravity update: if it is second order, why the first order is set
>>> to be
>>> > >>> the default?
>>> > >>> 3) I am puzzled by the several Riemann solvers. What is the
>>> hybrid solver?
>>> > >>> Why should I use hybrid, LLF or Marquina solver over the more
>>> standard Roe
>>> > >>> or HLLC?
>>> > >>> 4) The same can be asked about the different slope limiters...
>>> > >>> 5) ... or use_upwindTVD and use_3dFullCTU.
>>> > >>> Summarizing:a) what are your - general and specific -
>>> suggestions?b) why
>>> > >>> should I avoid or use a specific solver/option over other
>>> standard
>>> > >>> implementations?
>>> > >>> I think the unsplit module is a great part of FLASH, but all the
>>> > >>> parameters/options/solvers need to be better clarified. I hope
>>> you can
>>> > >>> help in that direction.Thank you in advance.Best,
>>> > >>>
>>> > >>> Max
>>> > >>>
>>> > >>
>>> > >
>>> > > --
>>> > > Paul M. Ricker
>>> > > Associate Professor of Astronomy
>>> > > University of Illinois
>>> > > pmricker at illinois.edu / 217-244-1187
>>> >
>>
>> !DSPAM:10175,4f38eb32141622473115232!
>