- removed comment
Test "Binary neutron star" example
Before each release, check that http://einsteintoolkit.org/gallery/bns/index.html still works and produces correct output.
Then upload the results file to https://bitbucket.org/einsteintoolkit/www/downloads/
Keyword: None
Comments (73)
-
reporter -
reporter - changed milestone to ET_2019_10
- edited description
-
reporter - changed status to resolved
-
reporter - removed responsible
- changed milestone to ET_2020_04
- marked as major
-
reporter - changed status to open
Opened for ET_2020_04 release.
-
reporter @Shawn R agreed to test this for 2020_04.
-
reporter - changed milestone to ET_2020_05
-
reporter For reference:
-
Bitbucket page to upload tarball of data: https://bitbucket.org/einsteintoolkit/www/downloads/
- tarball should be named bns-YYYYMMDD.tar.gz
-
Bitbucket repo to update website: https://bitbucket.org/einsteintoolkit/www
-
index.html
- link to up to date tarball
- update last run date
-
mp_Psi4
- rho.mp4
- rho.png
- rho_4x3.png
-
-
-
reporter Still images can be created from movie frames produced by
make_movie.sh
script using:# create still images for website cp rho_000000000.png rho.png convert -extract 300x225+214+195 rho.png rho_4x3.png
currently (as of hash 6db552c only rho_4x3.png is actually used).
-
reporter -
reporter - changed status to resolved
-
reporter - changed status to open
-
reporter - changed milestone to ET_2020_11
-
reporter Beyhan Karakaş volunteered (private email) to handle this for ET_2020_11.
-
reporter -
assigned issue to
-
assigned issue to
-
The gallery example “binary neutron star” was last successfully tested on 12 November 2020 and website was updated.
-
reporter - changed status to resolved
-
reporter - changed status to open
Reopened for 20201_05 release
-
reporter -
assigned issue to
-
assigned issue to
-
reporter - changed milestone to ET_2021_05
-
reporter In today’s ET call, https://docs.einsteintoolkit.org/et-docs/Meeting_agenda#2021-04-29, the issue of adding presync parameters was discussed and it was decided to try adding:
Cactus::presync_mode = "mixed-error"
to all gallery parfiles.
-
There is some issue with the nsnstohmns.th thornlist that is disrupting the download of NSTracker. The issue, as I understand, is that http://einsteintoolkit.org/gallery/bns/nsnstohmns.th accesses the link https://svn.cct.lsu.edu/repos/numrel/$1/$2/trunk which is dead and needs to be replaced with a new one.
I last downloaded ET with the nsnstohmns.th a couple weeks ago and all went well, so this must have come up recently.
-
reporter Uh right. The svn server svn.cct.lsu.edu was recently moved behind a firewall and is no longer publicly accessible. Though right now even when trying to access it from inside of LSU IP space (which worked fine yesterday) I get a error 500 internal server error.
@Peter Diener @Steven R. Brandt is there a LSUThorns Bitbucket or github place where the thorns that wwere in https://svn.cct.lsu.edu/repos/numrel could be hosted? From the email that I received from IT support it seemed to me that the svn server would not be made public again (“svn access is restricted to internal users now.”).
-
reporter For now I have put a copy of the required thorn (only the most recent revision which is all I had a copy of) to:
https://bitbucket.org/rhaas80/lsuthorns/src/master/
and you should be able to use it with a GetComponents line like so:
# LSU Thorns !TARGET = $ARR !TYPE = git !URL = https://bitbucket.org/rhaas80/lsuthorns.git !REPO_PATH= $2 !CHECKOUT = LSUThorns/NSTracker
-
Yes, that seems to be working for me.
Should I temporarily edit the thornlist on BNS website as well? Or we can discuss in the meeting tomorrow.
-
reporter I would rather not point anything to my Bitbucket repo since that repo really just contains the single revision of the code. The svn server seems down right now so even from within LSU one cannot get a fresh checkout with all version history for git. Also since the thorn was developed at LSU I would rather not take ownership of it in my personal Bitbucket account.
-
Thanks for that.
For the record, Presync enabled gives the following error:
Required read for SPHERICALSURFACE::sf_area[0] (rl=0) not satisfied. Have Nowhere and require Everywhere missing Everywhere at the start of routine CarpetMask::CarpetSurfaceSetup. Current valid state:
Valid entries: SPHERICALSURFACE::sf_area[0] (rl=0) Nowhere.Looks like an easy fix. I have no experience with both this thorn and presync to know how that can be done.
-
reporter @Frank Löffler provided (private email) a link to his own copy of the thorn in his Bitbucket repository https://bitbucket.org/knarrff/nstracker.git and I have updated the gallery thornlist accordingly in git hash 2c7bd5a "bns: use Frank Loeffler's bitbucket repo rather than LSU svn" of www
-
Thank you! I was wondering what the repo path should be changed to.
-
I reran the test on the Lorentz release version and am getting an error after certain time steps.
Traceback (most recent call last):
File "./simfactory/bin/../lib/sim.py", line 149, in <module>
main()
File "./simfactory/bin/../lib/sim.py", line 145, in main
CommandDispatch()
File "./simfactory/bin/../lib/sim.py", line 107, in CommandDispatch
module.main()
File "/afs/crc.nd.edu/user/a/akedia/etk_lorentz/Cactus/repos/simfactory2/lib/sim-manage.py", line 398, in main
CommandDispatch()
File "/afs/crc.nd.edu/user/a/akedia/etk_lorentz/Cactus/repos/simfactory2/lib/sim-manage.py", line 377, in CommandDispatch
exec("command_%s()" % command)
File "<string>", line 1, in <module>
File "/afs/crc.nd.edu/user/a/akedia/etk_lorentz/Cactus/repos/simfactory2/lib/sim-manage.py", line 185, in command_create_run
command_run()
File "/afs/crc.nd.edu/user/a/akedia/etk_lorentz/Cactus/repos/simfactory2/lib/sim-manage.py", line 222, in command_run
restart.userRun(simulationName)
File "/afs/crc.nd.edu/user/a/akedia/etk_lorentz/Cactus/repos/simfactory2/lib/simrestart.py", line 1014, in userRun
errfh.write(err_txt)
IOError: [Errno 5] Input/output errorThe two times I ran the test on Lorentz gave the same error although at different timesteps (t = 460 and t = 920)
I last tested the simulation on 17/May based on the master branch of ET and the run looked good then.
I think this is an issue on my machine’s end and I have some ideas for fixing it, and will be trying them until I post here again.
-
I am still getting the same error.
-
reporter Are you maybe running out of quota?
-
Ran again and it stopped at the same t ~ 920. No, not running out of quota.
-
- changed status to resolved
-
reporter - changed milestone to ET_2021_11
- removed responsible
-
reporter - changed status to open
-
reporter Alexandru Dima (UIUC) will handle this for ET_2021_11.
-
reporter Gabriele Bozzola provided some hints on how one could use kuibit (see there) instead of VisIt for the movies: https://bitbucket.org/einsteintoolkit/tickets/issues/2538/inclusion-of-kuibit#comment-61405883
-
reporter - changed status to resolved
-
When building ET using nsnstohmns.th I get the error
Processing CCL files CST error in /home/asksma/etk_submit1/Cactus/repos/flesh/lib/sbin/interface_parser.pl (at 637) -> NSTracker (thorn NSTracker) inherits from HYDRO_ANALYSIS No thorn in your current ThornList implements HYDRO_ANALYSIS Either remove NSTracker, or add a thorn to your ThornList implementing HYDRO_ANALYSIS Available thorns in arrangements directory implementing HYDRO_ANALYSIS: EinsteinAnalysis/Hydro_Analysis
and the same error for CactusNumerical/SphericalSurface
Does anyone know why this is happening? Looks like it is trying to build NSTracker before building thorns from einsteintoolkit.th.
-
reporter You need to pass
nsnstohms.th
to GetComponents first which should download the missing (non-ET) thorns. -
reporter - changed status to open
-
I tried getcomponents of either 1. just nsnstohmns.th or 2. both nsnstohmns.th and einsteintoolkit.th. Following which I do the simfactory build nsnstohmns.th command to get the error message in both cases.
-
reporter Hmm. Worksforme. These are the commands that I entered:
curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/master/GetComponents chmod a+x GetComponents ./GetComponents --root ET_NSNSToHMNS --parallel --shallow http://einsteintoolkit.org/gallery/bns/nsnstohmns.th cd ET_NSNSToHMNS/ ./simfactory/bin/sim setup-silent ./simfactory/bin/sim build --thornlist thornlists/nsnstohmns.th
Were there any warnings eg from GetComponents about not being able to check out all thorns?
-
I am doing almost the same procedure. I get the message 304 components checked out successfully after checkout, and the ones mentioned in the error also came through without errors.
-
reporter Let me be probe a bit more here. Which is he exact thorn list that you pass to simfacotyr (not GetComponents)? Could you maybe attach it to the ticket (otherwise we are mostly just guessing)? I am asking because you must not use the file nsnstohmns.th that GetComponents dropped into the directory it ran in (so
simfactory/bin/sim build --thornllist ../nsnstohmns.th
is incorrect) and you must instead use the one GetComponents writes tothornlists/nsnstohmns.th
which has the!INCLUDE
directive resolved. The one downloaded looks like so:# Component list for the Einstein Toolkit <http://einsteintoolkit.org/> # $Revision$ # $Date$ # $HeadURL$ !CRL_VERSION = 1.0 !INCLUDE = https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2021_11/einsteintoolkit.th !TARGET = $ARR !TYPE = git !URL = https://bitbucket.org/knarrff/nstracker.git !REPO_PATH = ../../arrangements/$1/../../repos/nstracker !CHECKOUT = LSUThorns/NSTracker
and does (for me at least) produce an error message:
------------------------------------------------------ There were 2 errors during execution of the CST These must be corrected before compilation can proceed ------------------------------------------------------ ------------------------------------------------------ Warnings were generated during execution of the CST ------------------------------------------------------ CST error in /data/rhaas/postdoc/gr/cactus/ET_NSNSToHMNS/repos/flesh/lib/sbin/interface_parser.pl (at 637) -> NSTracker (thorn NSTracker) inherits from HYDRO_ANALYSIS No thorn in your current ThornList implements HYDRO_ANALYSIS Either remove NSTracker, or add a thorn to your ThornList implementing HYDRO_ANALYSIS Available thorns in arrangements directory implementing HYDRO_ANALYSIS: EinsteinAnalysis/Hydro_Analysis CST error in /data/rhaas/postdoc/gr/cactus/ET_NSNSToHMNS/repos/flesh/lib/sbin/interface_parser.pl (at 637) -> NSTracker (thorn NSTracker) inherits from SPHERICALSURFACE No thorn in your current ThornList implements SPHERICALSURFACE Either remove NSTracker, or add a thorn to your ThornList implementing SPHERICALSURFACE Available thorns in arrangements directory implementing SPHERICALSURFACE: CactusNumerical/SphericalSurface
when passed to simfactory.
-
Thanks Roland, that was it. I had forgotten that the thorn in Cactus/thornlists needs to be passed instead of the ../nsnstohmns.th.
-
- changed status to resolved
-
reporter - changed status to open
-
reporter - changed milestone to ET_2022_11
-
reporter Johnny Tsao will test this for ET_2022_11.
-
reporter - edited description
-
For 2022_11_ET BNS gallery test: when building from the thornlist
./simfactory/bin/sim build bns --thornlist thornlists/nsnstohmns.th
, I got the following error when compiling theExternalLibraries/LORENE
thorn.patching file Lorene/C++/Source/Bin_hor/Makefile patch: **** can't open file Lorene/C++/Source/Bin_hor/Makefile_lib : Too many open files make[3]: *** [/home/bt22824/2022_11_ETK/Cactus/arrangements/ExternalLibraries/LORENE/src/make.code.deps:14: /home/bt22824/2022_11_ETK/Cactus/configs/bns/scratch/done/LORENE] Error 2 make[2]: *** [/home/bt22824/2022_11_ETK/Cactus/lib/make/make.thornlib:113: make.checked] Error 2 make[1]: *** [/home/bt22824/2022_11_ETK/Cactus/lib/make/make.configuration:179: /home/bt22824/2022_11_ETK/Cactus/configs/bns/lib/libthorn_LORENE.a] Error 2
For reference, here are the commands I used to download the current master version of ET
curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/master/GetComponents chmod a+x GetComponents ./GetComponents --parallel --shallow https://bitbucket.org/einsteintoolkit/manifest/raw/master/einsteintoolkit.th ./GetComponents http://einsteintoolkit.org/gallery/bns/nsnstohmns.th
This actually also occurs in an older ETK version I had (2021_05) when compiling the new thornlist
nsnstohmns.th
from 2022_05 release.
-
reporter Are you compiling on a cluster (which one)? In that case, it could be a limit imposed by the admins. Would you mind trying with
./simfactory/bin/sim build -j1 bns
to use only a single parallel make process? Also if you could provide the output ofulimit -a
that would help. -
reporter Did you have any luck finding out what went wrong with the build?
-
It seems like the issue only occurs when building on a local machine, but not on a cluster (i.e. Frontera, Expanse). On a local machine, the same error from Lorene still shows up even when restricting to a single make process.
./simfactory/bin/sim build -j1 bns --thornlist thornlists/nsnstohmns.th
Since the issue only occurs on the local machine, perhaps some compiling packages on the machine should be updated to resolve the issue (linux machine last updated last year around October from https://github.com/nds-org/jupyter-et/blob/master/tutorial-server/notebooks/CactusTutorial.ipynb).
-
reporter On the local machine (with the failure), what is the output of
ulimit -a
? “local” here means all local file systems, not anything (eg $HOME) mounted via NFS? (trying to understand what may be going on). -
core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 126665 max locked memory (kbytes, -l) 65536 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 126665 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Here is the output with
ulimit -a
. You are correct, this is actually ran on a computer that is shared among our group members.
-
reporter Hmm, not any different from my laptop (which also shows the 1024 open files restriction).
real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 78729 max locked memory (kbytes, -l) 2526916 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 78729 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
-
BNS gallery example (bns-20221027) is updated on the website.
Notes on running BNS gallery example (10-27):
- Gnuplot issue with epstopdf and convert: need to update gnuplot and allow read/write access with ImageMagick.
- Add python script to plot Psi4 using kuibit instead (plot_quibit.py in script.tar.gz).
- Compiling issue with LORENE: might not have the latest version of cmake, resolved by running on Expanse and Frontera. -
reporter - changed status to resolved
-
reporter - changed status to open
I will test this for ET_2023_05.
-
reporter -
reporter - changed milestone to ET_2023_05
-
reporter -
assigned issue to
-
assigned issue to
-
reporter I updated the website and the data. The gallery example now uses higher resolution.
-
- changed status to resolved
-
reporter - changed status to open
-
reporter - changed milestone to ET_2023_11
-
assigned issue to
-
reporter @Steven R. Brandt will handle this for ET_2023_11
-
@Steven R. Brandt @Roland Haas was this ever resolved in the previous release? I recall you saying the results differed, but never received any updates.
-
reporter I think some differences were post-merger only (so expected) and some were missing data in the re-run.
The current setup uses higher resolution than the very old ones, so will look a bit different than say a 2019 run.
-
reporter - changed milestone to ET_2024_05
- removed responsible_account_id
- Log in to comment
Previous work on this is in here: https://bitbucket.org/einsteintoolkit/tickets/issues/2119