[Users] Question about GRHydro + LLAMA

[Luciano Combi]

That's great, thank you very much, Roland.

Cheers.

El mar, 4 may 2021 a las 11:17, Roland Haas (<rhaas at illinois.edu>) escribió:

> Hello Luciano,
>
> > I'm a relatively new user of the toolkit; I've been mainly using GRHydro
> > and I'd like to start using it with LLAMA. I played a bit with the
> > multipatch gallery example but I have a few questions:
> >
> > 1) Is there a public parfile for a simple TOV or any GRHydro
> implementation
> > using LLAMA (or someone I could ask about it)?
> Not sure about fully public, but you are free to use the attached one
> that was used in
>
> https://arxiv.org/abs/1212.1191
>
> though it uses CTGamma rather than McLachlan so will require some
> adaptation (or you can use CTGamma which is available in the Llama
> repo). It also uses some private thorns (CCCGlobalModes and
> Psiclops, WaveExtractL) which you can either remove or use eg
> Hydro_Analysis for CCCGlobalModes, and WeylScal and Multipole the way
> the GW150914 example does for the waves.
>
> Note: there is nothing really that needs to be done use GRhydro with
> Llama, other than setting up the grid, ie it needs no extra parameters
> so a Llama parfile could be constructed by merging the gallery bns
> example with the gallery GW150914 example (at reduced finite difference
> order since order 8 is overkill for a hydro run).
>
> You may also take a look at the Parma group's collection of data and
> files (some digging in the website required) starting from here:
>
> https://docs.einsteintoolkit.org/et-docs/Additional_resources
>
> though there is no Llama files I think.
>
> Note that due to the way NSTracker works, the parfile will only work
> with equal mass bns systems. For unqual ones the WVUThorns_Analysis has
> thorns that can track each bns separately (those thorns won't work with
> symmetry enabled but should work with Llama as long as the NS are only
> on the Cartesian grid).
>
> > 2) Reading the mailing list I found that there was an issue with the GW
> > propagation caused by refinement boundaries (
> >
> https://urldefense.com/v3/__http://lists.einsteintoolkit.org/pipermail/users/2017-March/005411.html__;!!DZ3fjg!q8UZ3uoTcF5BGa-3mdV_BF1Sdv9tQjnP3RipvVq7Mt4xIi_Kc32UI63Ga10flgmj$
> ).
>
> I would say those still exist, though there is a possibility that
> changes due to
>
>
> https://bitbucket.org/einsteintoolkit/tickets/issues/2398/multipole-default-midpoint-integration
>
> have changed behaviour a bit.
>
> > Do you know if this is still an issue?
>
> I would not say "know", but my guess would be "yes, still an issue to
> the extend reported by Christian".
>
> > If I get to use it, I'd be happy to contribute in some way, if there's
> room
> > and interest for that.
> If you can make the parfile simpler and eg baesd on the bns gallery
> example and were to contribute it back, than would be very nice to have.
>
> Yours,
> Roland
>
> --
> My email is as private as my paper mail. I therefore support encrypting
> and signing email messages. Get my PGP key from http://pgp.mit.edu .
>


-- 
*Luc Combi*
Instituto Argentino de Radioastronomía
CONICET, Buenos Aires, Argentina
web page. <http://sites.google.com/view/lucianocombi>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20210505/c9930bf1/attachment.html