Dear all,
I've encountered the error below while trying to run a parameter file on a cluster. Surprisingly, for the same parameter file (and the same version of ET: 2024-05) on my local work station, this does not occur. This appears very early in the execution, at parameter setting.
WARNING[L2,P0] (Cactus): ParameterSetReal: Unable to set real 'Coordinates::h_radial_1' = '4' not in any active range WARNING[L1,P0] (Cactus): Major error in parameter file '/home/jnicoules/Work/ET/Simus/parfiles/HairyBH/HairyBH_sol02_MLBSSN_llama_run02bis.par' line 94: Range error setting parameter 'Coordinates::h_radial_1' to '4'
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.
Best,
Jordan Nicoules
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
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@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 .
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@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 .
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@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@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 .
Hello Jordan,
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.
The hash that is shown in the docs is a git commit hash of the Cactus repository (the "flesh") so I can correlate with the release.
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.
Ok, it working on a workstation and failing on another (or cluster, https://en.wikipedia.org/wiki/Deucalion_(supercomputer) ?) is very strange.
Would you be able to send me the option lists for those two and also the files configs/<FOO>/config-data/make.config.defn ? The latter are the fully parsed files that make constructs using the option list and other information.
Isn't ET_2025_05 the latest?
It is the latest yes.
Yours, Roland
Hi Roland,
Indeed, Deucalion is a cluster (as well as MesoPSL and MareNostrum, which I checked before sending my previous email, and which seem to work just fine with the "*" range as expected).
I'm attaching the requested files:
- for the work station: relayer_ubuntu.cfg, workstation_make.config.defn
- for the Deucalion cluster: deucalion-x86.cfg, deucalion_make.config.defn
These are from the minimal working example I was mentioning before, with the latest ET version.
Thank you for your assistance!
Best,
Jordan
________________________________ From: Roland Haas rhaas@mail.ubc.ca Sent: Friday, February 27, 2026 3:30:09 PM To: Jordan Nicoules Cc: Jordan Nicoules via Users 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,
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.
The hash that is shown in the docs is a git commit hash of the Cactus repository (the "flesh") so I can correlate with the release.
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.
Ok, it working on a workstation and failing on another (or cluster, https://en.wikipedia.org/wiki/Deucalion_(supercomputer) ?) is very strange.
Would you be able to send me the option lists for those two and also the files configs/<FOO>/config-data/make.config.defn ? The latter are the fully parsed files that make constructs using the option list and other information.
Isn't ET_2025_05 the latest?
It is the latest yes.
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 .
Hello Jordan,
We discussed this some more in today's ET call and Peter Diener suggested trying a different compiler on Deucalian just in case this is actually a compiler issue.
Yours, Roland
[CAUTION: Non-UBC Email]
Hi Roland,
Indeed, Deucalion is a cluster (as well as MesoPSL and MareNostrum, which I checked before sending my previous email, and which seem to work just fine with the "*" range as expected).
I'm attaching the requested files:
for the work station: relayer_ubuntu.cfg, workstation_make.config.defn
for the Deucalion cluster: deucalion-x86.cfg, deucalion_make.config.defn
These are from the minimal working example I was mentioning before, with the latest ET version.
Thank you for your assistance!
Best,
Jordan
From: Roland Haas rhaas@mail.ubc.ca Sent: Friday, February 27, 2026 3:30:09 PM To: Jordan Nicoules Cc: Jordan Nicoules via Users 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,
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.
The hash that is shown in the docs is a git commit hash of the Cactus repository (the "flesh") so I can correlate with the release.
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.
Ok, it working on a workstation and failing on another (or cluster, https://en.wikipedia.org/wiki/Deucalion_(supercomputer) ?) is very strange.
Would you be able to send me the option lists for those two and also the files configs/<FOO>/config-data/make.config.defn ? The latter are the fully parsed files that make constructs using the option list and other information.
Isn't ET_2025_05 the latest?
It is the latest yes.
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 .
Hi Roland (and Peter),
Thank you for the suggestion! This was very relevant.
With loaded modules related to GCC-13.3.0 (and GCC-14.3.0), the error is occurring, while for GCC-12.3.0, the range is working as expected. This is compatible with the experiment on other clusters and on my work station, which have lower versions of gcc as well.
What should be made of that knowledge? Should I file a ticket? I suppose that in the future, this may be ever more likely to occur. (For my individual case, it's fine, I can deal with it.)
Best,
Jordan
________________________________ From: Roland Haas rhaas@mail.ubc.ca Sent: Thursday, March 12, 2026 2:33:03 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,
We discussed this some more in today's ET call and Peter Diener suggested trying a different compiler on Deucalian just in case this is actually a compiler issue.
Yours, Roland
[CAUTION: Non-UBC Email]
Hi Roland,
Indeed, Deucalion is a cluster (as well as MesoPSL and MareNostrum, which I checked before sending my previous email, and which seem to work just fine with the "*" range as expected).
I'm attaching the requested files:
for the work station: relayer_ubuntu.cfg, workstation_make.config.defn
for the Deucalion cluster: deucalion-x86.cfg, deucalion_make.config.defn
These are from the minimal working example I was mentioning before, with the latest ET version.
Thank you for your assistance!
Best,
Jordan
From: Roland Haas rhaas@mail.ubc.ca Sent: Friday, February 27, 2026 3:30:09 PM To: Jordan Nicoules Cc: Jordan Nicoules via Users 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,
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.
The hash that is shown in the docs is a git commit hash of the Cactus repository (the "flesh") so I can correlate with the release.
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.
Ok, it working on a workstation and failing on another (or cluster, https://en.wikipedia.org/wiki/Deucalion_(supercomputer) ?) is very strange.
Would you be able to send me the option lists for those two and also the files configs/<FOO>/config-data/make.config.defn ? The latter are the fully parsed files that make constructs using the option list and other information.
Isn't ET_2025_05 the latest?
It is the latest yes.
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 .
Hello Jordan,
Adding this to the ticket would be great.
On my workstation I have gcc-15 and things work well there, so this may be only some specific version that is affected, so knowing the exact number is helpful (one could even compile that version and test).
Yours, Roland
[CAUTION: Non-UBC Email]
Hi Roland (and Peter),
Thank you for the suggestion! This was very relevant.
With loaded modules related to GCC-13.3.0 (and GCC-14.3.0), the error is occurring, while for GCC-12.3.0, the range is working as expected. This is compatible with the experiment on other clusters and on my work station, which have lower versions of gcc as well.
What should be made of that knowledge? Should I file a ticket? I suppose that in the future, this may be ever more likely to occur. (For my individual case, it's fine, I can deal with it.)
Best,
Jordan
From: Roland Haas rhaas@mail.ubc.ca Sent: Thursday, March 12, 2026 2:33:03 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,
We discussed this some more in today's ET call and Peter Diener suggested trying a different compiler on Deucalian just in case this is actually a compiler issue.
Yours, Roland
[CAUTION: Non-UBC Email]
Hi Roland,
Indeed, Deucalion is a cluster (as well as MesoPSL and MareNostrum, which I checked before sending my previous email, and which seem to work just fine with the "*" range as expected).
I'm attaching the requested files:
for the work station: relayer_ubuntu.cfg, workstation_make.config.defn
for the Deucalion cluster: deucalion-x86.cfg, deucalion_make.config.defn
These are from the minimal working example I was mentioning before, with the latest ET version.
Thank you for your assistance!
Best,
Jordan
From: Roland Haas rhaas@mail.ubc.ca Sent: Friday, February 27, 2026 3:30:09 PM To: Jordan Nicoules Cc: Jordan Nicoules via Users 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,
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.
The hash that is shown in the docs is a git commit hash of the Cactus repository (the "flesh") so I can correlate with the release.
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.
Ok, it working on a workstation and failing on another (or cluster, https://en.wikipedia.org/wiki/Deucalion_(supercomputer) ?) is very strange.
Would you be able to send me the option lists for those two and also the files configs/<FOO>/config-data/make.config.defn ? The latter are the fully parsed files that make constructs using the option list and other information.
Isn't ET_2025_05 the latest?
It is the latest yes.
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 .
Hi Roland,
I have just created a new ticket to report the issue more cleanly. I included a minimal (non-)working example and configuration related information, that hopefully should help reproduce the issue. Sorry I couldn't do it sooner. Unfortunately, I probably won't be able to join the weekly meeting tomorrow.
Best,
Jordan
________________________________ From: Roland Haas rhaas@mail.ubc.ca Sent: Wednesday, March 18, 2026 4:18:01 PM To: Jordan Nicoules Cc: Jordan Nicoules via Users 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,
Adding this to the ticket would be great.
On my workstation I have gcc-15 and things work well there, so this may be only some specific version that is affected, so knowing the exact number is helpful (one could even compile that version and test).
Yours, Roland
[CAUTION: Non-UBC Email]
Hi Roland (and Peter),
Thank you for the suggestion! This was very relevant.
With loaded modules related to GCC-13.3.0 (and GCC-14.3.0), the error is occurring, while for GCC-12.3.0, the range is working as expected. This is compatible with the experiment on other clusters and on my work station, which have lower versions of gcc as well.
What should be made of that knowledge? Should I file a ticket? I suppose that in the future, this may be ever more likely to occur. (For my individual case, it's fine, I can deal with it.)
Best,
Jordan
From: Roland Haas rhaas@mail.ubc.ca Sent: Thursday, March 12, 2026 2:33:03 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,
We discussed this some more in today's ET call and Peter Diener suggested trying a different compiler on Deucalian just in case this is actually a compiler issue.
Yours, Roland
[CAUTION: Non-UBC Email]
Hi Roland,
Indeed, Deucalion is a cluster (as well as MesoPSL and MareNostrum, which I checked before sending my previous email, and which seem to work just fine with the "*" range as expected).
I'm attaching the requested files:
for the work station: relayer_ubuntu.cfg, workstation_make.config.defn
for the Deucalion cluster: deucalion-x86.cfg, deucalion_make.config.defn
These are from the minimal working example I was mentioning before, with the latest ET version.
Thank you for your assistance!
Best,
Jordan
From: Roland Haas rhaas@mail.ubc.ca Sent: Friday, February 27, 2026 3:30:09 PM To: Jordan Nicoules Cc: Jordan Nicoules via Users 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,
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.
The hash that is shown in the docs is a git commit hash of the Cactus repository (the "flesh") so I can correlate with the release.
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.
Ok, it working on a workstation and failing on another (or cluster, https://en.wikipedia.org/wiki/Deucalion_(supercomputer) ?) is very strange.
Would you be able to send me the option lists for those two and also the files configs/<FOO>/config-data/make.config.defn ? The latter are the fully parsed files that make constructs using the option list and other information.
Isn't ET_2025_05 the latest?
It is the latest yes.
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 .
-- 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@lists.einsteintoolkit.org
-
Jordan Nicoules -
Roland Haas