[Users] Range error setting parameter, on cluster

[Jordan Nicoules]

Hi Roland,


Well, I don't know if the git hash corresponds to the ET release directly (I took it from the front page of the UsersGuide.pdf I have on my work station). The corresponding ET release should be ET_2024_05 I think.


I'm not sure this is (completely) a matter of version, since for a given version, I get different behaviors on different machines:

- ET_2024_05: Deucalion --> range error ; work station --> fine

- ET_2025_05: Deucalion --> range error ; work station, MesoPSL, MareNostrum --> all fine.

Isn't ET_2025_05 the latest?


Best,


Jordan

________________________________
From: Roland Haas <rhaas at mail.ubc.ca>
Sent: Thursday, February 26, 2026 3:00:49 PM
To: Jordan Nicoules via Users
Cc: Jordan Nicoules
Subject: Re: [Users] Range error setting parameter, on cluster


CUIDADO: Email de um sistema externo. Cuidado com links, anexos e pedidos de dados/senhas.
CAUTION: Email from an external system. Be careful with links, attachments, and requests for data/passwords.

Hello Jordan,

Hmm, worksforme with the current ET version. I will need to give the
version of your git hash a try.

Yours,
Roland

> [CAUTION: Non-UBC Email]
>
> Hi Roland,
>
>
> Thank you for your message.
>
> In the local version I have from the docs (UsersGuide.pdf version 4.14 commit cd7e0d57217bec3023091c951729faf982cf5f54), it gets mentioned in paragraph D2.3.2, in the INT case (REAL being the same),
>
> -----
> Here, a <range description> specifies a set of integers, and has one of the
> following forms:
> *                              # means any integer
> -----
>
> Regardless, it seems that the param.ccl from Coordinate still uses just * for h_radial_1.
>
> Rather than my actual par file, here is a more minimal working example (attached par file), derived from the Kerr-Schild_Multipole gallery example. I'm attaching the output file of the simulation. Note that a test without radial stretching did run properly - and so does a run with stretching when the range in param.ccl is *:* .
>
> For these tests, I made a fresh installation of the toolkit on the cluster (Deucalion), with the versions of GetComponents and the thornlist indicated at https://einsteintoolkit.org/download.html (in particular, !DEFINE ET_RELEASE = ET_2025_05). I've just commented out some thorns (typically CarpetX related). I am attaching the config file and thornlist, if it can be insightful. I can provide the log files containing the output of "make config" and "make" commands if needed.
>
> Best,
>
> Jordan
>
>
>
>
> ________________________________
> From: Roland Haas <rhaas at mail.ubc.ca>
> Sent: Thursday, February 12, 2026 15:15
> To: Jordan Nicoules via Users
> Cc: Jordan Nicoules
> Subject: Re: [Users] Range error setting parameter, on cluster
>
>
> CUIDADO: Email de um sistema externo. Cuidado com links, anexos e pedidos de dados/senhas.
> CAUTION: Email from an external system. Be careful with links, attachments, and requests for data/passwords.
>
> Hello Jordan,
>
> > In the param.ccl of the Coordinate thorn, the range of this parameter
> > appears as
> >
> >   * :: "negative turns off stretching"
> > Changing the * range statement to *:* makes it work on the cluster.
> >
> > Is this some known issue? Is there something specific to look for, in
> > the Cactus configuration for instance? So far, I haven't thoroughly
> > tested ET versions, different clusters etc, but I can try to provide
> > more information if needed.
>
> Hmm, the docs
>
> https://einsteintoolkit.org/usersguide/UsersGuide.html#x1-70000
>
> are not explicit about this.
>
> I have certainly used it like this:
>
> --8<--
> Coordinates::radial_stretch = "yes"
> Coordinates::stretch_rmin_1 = $outermost_detector + 2.*$initial_orbital_period
> Coordinates::stretch_rmax_1 = $outermost_detector + 4.*$initial_orbital_period
> Coordinates::h_radial_1     = 4 * $hr
> --8<--
>
> in files of my own (with $hr having been set before).
>
> Can you attach the full parameter file maybe?
>
> 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 .

--
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 .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20260227/a15e94c3/attachment.htm>