thanks Roland! this should be enough to get me started. i'll report back if i run into any difficulty.

cheers, Miguel

On 22/04/19 13:32, Haas, Roland wrote:

Hello Miguel,

I gave a tutorial on this (for a WaveToy code) at the NCSA ET meeting:

https://drive.google.com/open?id=0B4gNfWainf-5dGcxQzNuOUtEUFk

The code is (likely, given its name) in the the "rhaas/llama" branch of the cactusexample repo:

cd repos/cactusexamples git checkout rhaas/llama

should get them for you.

Yours, Roland

...

hi all,

i have a few evolution codes that i would like to make Llama-aware. one of them would be the LeanBSSNMoL thorn, that was included in the latest ET release.

is there a canonical procedure to do this, or any documentation that i should follow? i understand that the main thing to change are the finite differencing operations... is there a standard way of performing this change? or anything else i should be aware of?

thanks, Miguel _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users

Hello Miguel,

There may be two issues:

1. You do not have to inherit from Coordinates to use functions provided by Coordinates.

2. You do however need to inherit to get easy access to the Jacobian though. To avoid this you need to call the (low level) function CCTK_VarDataPtr to get access to the Jacobian at runtime depending on whether you want to use it. Then when you need an if statement based on this decision to apply / not apply the Jacobian. This then is a bit more complex.

Basically (this is inspired by McLachlan):

const CCTK_REAL *J11 = use_jacobian ? CCTK_VarDataPtr(cctkGH, 0, "Coordinates::J11") : NULL; for(ijk) { CCTK_REAL phi_x = phi[i+1] - phi[i-1]; CCTK_REAL phi_y = phi[j+1] - phi[j-1]; if (use_jacobian) { // apply jacobian to derivatives (or so) CCTK_REAL Jac_phi_x = J11 * phi_x + J12 * phi_y; CCTK_REAL Jac_phi_y = J12 * phi_x + J22 * phi_y; phi_x = Jac_phi_x; phi_y = Jac_phi_y; } }

Yours, Roland

hi again,

i have a follow-up question regarding this. i'm following Roland's implementation of the WaveToy code with Llama, and i'm running into the following issue.

when i inherit the Coordinates thorn, the function MultiPatch_GetDomainSpecification becomes aliased, and this becomes a problem if i want to use the same thorn and *not* use Llama. in order words, when adding

inherits: Coordinates

to a thorn's interface.ccl file, one then needs to activate the Coordinates thorn in the parfile upon running the code whether or not one wants to use Llama. but then, if multipatch is not used (ie, with Carpet::domain_from_coordbase = yes), the following error occurs:

void Carpet::get_domain_specification(const cGH*, int, const ivect&, CarpetLib::rvect&, CarpetLib::rvect&, CarpetLib::rvect&): Assertion `not CCTK_IsFunctionAliased("MultiPatch_GetDomainSpecification")' failed.

is there a simple way of having a Llama-aware thorn which can also run without multipatch if so desired?

i've found a previous discussion with a similar issue (http://lists.einsteintoolkit.org/pipermail/users/2015-December/004656.html) when using CTGamma, where the suggestion was to activate the thorn CTGamma/CartesianCoordinates when not using multipatch. i'm guessing that this thorn provides all the grid functions that Coordinates provides?

is this then the only solution, ie, creating a helper thorn with a "trivial" Coordinates implementation?

thanks, Miguel

On 22/04/19 21:45, Miguel Zilhão wrote:

...

thanks Roland! this should be enough to get me started. i'll report back if i run into any difficulty.

cheers, Miguel

On 22/04/19 13:32, Haas, Roland wrote:

...

Hello Miguel,

I gave a tutorial on this (for a WaveToy code) at the NCSA ET meeting:

https://drive.google.com/open?id=0B4gNfWainf-5dGcxQzNuOUtEUFk

The code is (likely, given its name) in the the "rhaas/llama" branch of the cactusexample repo:

cd repos/cactusexamples git checkout rhaas/llama

should get them for you.

Yours, Roland

...

hi all,

i have a few evolution codes that i would like to make Llama-aware. one of them would be the LeanBSSNMoL thorn, that was included in the latest ET release.

is there a canonical procedure to do this, or any documentation that i should follow? i understand that the main thing to change are the finite differencing operations... is there a standard way of performing this change? or anything else i should be aware of?

thanks, Miguel _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users

---

Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users

hi Ian,

yes, i guess the CartesianCoordinate thorn could work. this is not part of the ET, though, is it?

thanks, Miguel

On 09/05/19 22:16, Ian Hinder wrote:

Hi Miguel,

There is also the CartesianCoordinate thorn, which implements "Coordinates", but which just provides a Cartesian grid.  Would this be sufficient?

...

On 9 May 2019, at 00:31, Haas, Roland <rhaas@illinois.edu mailto:rhaas@illinois.edu> wrote:

Hello Miguel,

There may be two issues:

1. You do not have to inherit from Coordinates to use functions

provided by Coordinates.

2. You do however need to inherit to get easy access to the Jacobian

though. To avoid this you need to call the (low level) function CCTK_VarDataPtr to get access to the Jacobian at runtime depending on whether you want to use it. Then when you need an if statement based on this decision to apply / not apply the Jacobian. This then is a bit more complex.

Basically (this is inspired by McLachlan):

const CCTK_REAL *J11 = use_jacobian ?  CCTK_VarDataPtr(cctkGH, 0, "Coordinates::J11") : NULL; for(ijk) {  CCTK_REAL phi_x = phi[i+1] - phi[i-1];  CCTK_REAL phi_y = phi[j+1] - phi[j-1];  if (use_jacobian) {    // apply jacobian to derivatives (or so)    CCTK_REAL Jac_phi_x = J11 * phi_x + J12 * phi_y;    CCTK_REAL Jac_phi_y = J12 * phi_x + J22 * phi_y;    phi_x = Jac_phi_x;    phi_y = Jac_phi_y;  } }

Yours, Roland

...

hi again,

i have a follow-up question regarding this. i'm following Roland's implementation of the WaveToy code with Llama, and i'm running into the following issue.

when i inherit the Coordinates thorn, the function MultiPatch_GetDomainSpecification becomes aliased, and this becomes a problem if i want to use the same thorn and *not* use Llama. in order words, when adding

inherits: Coordinates

to a thorn's interface.ccl file, one then needs to activate the Coordinates thorn in the parfile upon running the code whether or not one wants to use Llama. but then, if multipatch is not used (ie, with Carpet::domain_from_coordbase = yes), the following error occurs:

void Carpet::get_domain_specification(const cGH*, int, const ivect&,   CarpetLib::rvect&, CarpetLib::rvect&, CarpetLib::rvect&): Assertion `not   CCTK_IsFunctionAliased("MultiPatch_GetDomainSpecification")' failed.

is there a simple way of having a Llama-aware thorn which can also run without multipatch if so desired?

i've found a previous discussion with a similar issue (http://lists.einsteintoolkit.org/pipermail/users/2015-December/004656.html) when using CTGamma, where the suggestion was to activate the thorn CTGamma/CartesianCoordinates when not using multipatch. i'm guessing that this thorn provides all the grid functions that Coordinates provides?

is this then the only solution, ie, creating a helper thorn with a "trivial" Coordinates implementation?

thanks, Miguel

On 22/04/19 21:45, Miguel Zilhão wrote:

...

thanks Roland! this should be enough to get me started. i'll report back if i run into any difficulty.

cheers, Miguel

On 22/04/19 13:32, Haas, Roland wrote:

...

Hello Miguel,

I gave a tutorial on this (for a WaveToy code) at the NCSA ET meeting:

https://drive.google.com/open?id=0B4gNfWainf-5dGcxQzNuOUtEUFk

The code is (likely, given its name) in the the "rhaas/llama" branch of the cactusexample repo:

cd repos/cactusexamples git checkout rhaas/llama

should get them for you.

Yours, Roland

...

hi all,

i have a few evolution codes that i would like to make Llama-aware. one of them would be the LeanBSSNMoL thorn, that was included in the latest ET release.

is there a canonical procedure to do this, or any documentation that i should follow? i understand that the main thing to change are the finite differencing operations... is there a standard way of performing this change? or anything else i should be aware of?

thanks, Miguel _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users

---

Users mailing list Users@einsteintoolkit.org mailto:Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users

-- 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 . _______________________________________________ Users mailing list Users@einsteintoolkit.org mailto:Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users

-- Ian Hinder Research Software Engineer University of Manchester, UK

Hello Ian, Miguel,

using CartesianCoordinates is almost the same as using Coordinates with its (default) "cartesian" patch. Only almost b/c of two things:

* CartesianCoordinates does not provide the function MultiPatch_GetDomainSpecification and the others that Coordinates provides (eg MultiPatch_GetBoundarySpecification) * Coordinates has parameters ncells_[xyz] and patch_[xyz]{min,max} that describe its single Cartesian patch (used by MultiPatch_GetDomainSpecification) Yours,

so basically CartesianCoordinates provides the grid functions to make typical science codes work but not enough to make eg CartGrid3D's CartGrid3D::type = "multipatch" or Carpet::domain_from_multipatch work.

One could almost use Coordinates with its default values for ncells and the patch sizes as a replacement for CartesianCoords since the values of the missing parameters are only accessible via the aliased functions that CartesianCoordinates is missing.

However Carpet currently torpedoes any such attempt since it requires that the aliased function "MultiPatch_GetDomainSpecification" is missing unless Carpet::domain_from_multipatch is set. Further CarpetRegrid2 and CarpetMask will use MultiPatch_XXX if it exists obtaining incorrect results.

The only reason CartesianCoordinates was not proposed for the ET was that Llama itself was included so at that point the idea was that one could use Coordinates with its "cartesian" patch type for these cases. However as outlined in the paragraph above that is only almost true.

Yours, Roland

On 10 May 2019, at 10:22, Miguel Zilhão <miguel.zilhao.nogueira@tecnico.ulisboa.ptmailto:miguel.zilhao.nogueira@tecnico.ulisboa.pt> wrote:

hi Ian,

yes, i guess the CartesianCoordinate thorn could work. this is not part of the ET, though, is it?

Hi Miguel,

You're right; I hadn't realised this. It's in the CTGamma arrangement:

https://bitbucket.org/llamacode/ctgamma/src/master/

but is not part of the toolkit. Just clone CTGamma into arrangements and add CTGamma/CartesianCoordinates to the thornlist and recompile.

-- Ian Hinder Research Software Engineer University of Manchester, UK