From I.Hawke at soton.ac.uk Mon Jan 8 03:58:15 2024 From: I.Hawke at soton.ac.uk (Ian Hawke) Date: Mon, 8 Jan 2024 09:58:15 +0000 Subject: [Users] Postdoctoral positions at University of Southampton Message-ID: Dear Colleagues, Happy New Year and best wishes for 2024 to everyone! The Gravity group at the University of Southampton is seeking applications to fill three Postdoctoral positions in gravitational-wave astrophysics. Each position is available for two years with a start date of 1 October 2024. The Southampton group is one of the leading modelling groups in gravitational-wave astronomy in Europe, currently comprising 7 staff members and a number of postdocs and PhD students. Research in the group includes black-hole and neutron-star physics, gravitational-wave source modelling and data analysis, numerical relativity and gravitational self-force modelling. Members of the group are actively involved with the LIGO Scientific Collaboration, the Einstein Telescope and Cosmic Explorer Collaborations and the LISA Consortium. 1) Senior Research Fellow in Gravitational-Wave Physics The successful candidate will undertake research to establish the science case for the next generation of gravitational-wave observatories, Cosmic Explorer and Einstein Telescope. Particular focus will be on understanding the network capability to constrain aspects of neutron-star physics. The ideal applicant will have a track record in at least one of the following research areas: gravitational-wave astronomy and data analysis, neutron star modelling and numerical relativity. The post is supported by UKRI funding for next-generation gravitational waves and the research will be carried out jointly with colleagues at the Universities of Cardiff and Birmingham. For further details and applications, see https://jobs.soton.ac.uk/Vacancy.aspx?ref=2568324PJ 2) Research Fellow in Numerical Relativity The successful candidate will contribute to work aimed at carrying out numerical simulations of neutron star mergers with realistic physics, with particular focus on resistive magnetohydrodynamics. The ideal applicant will have a track record in numerical relativity and some understanding of neutron star modelling, gravitational-wave astronomy and data analysis. For further details and applications, see https://jobs.soton.ac.uk/Vacancy.aspx?ref=2567724PJ 3) Research Fellow in Gravitational-Wave Physics The successful candidate will contribute to developing an accurate description of dynamical tides for models involving realistic neutron-star physics. The ideal applicant will have a track record in neutron star modelling and gravitational-wave astronomy and some understanding of related data analysis. For further details and applications, see https://jobs.soton.ac.uk/Vacancy.aspx?ref=2568724PJ Applicants are expected to have, or be about to obtain, a relevant PhD degree in physics or mathematics. The closing date for all applications is Thursday 25 January 2024. For informal enquiries about these posts please contact Nils Andersson N.Andersson at soton.ac.uk, Ian Jones dij at maths.soton.ac.uk or Ian Hawke I.Hawke at soton.ac.uk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Mon Jan 8 15:18:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 08 Jan 2024 15:18:01 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers From rhaas at illinois.edu Wed Jan 10 17:15:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 10 Jan 2024 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers From rhaas at illinois.edu Thu Jan 11 09:38:36 2024 From: rhaas at illinois.edu (Roland Haas) Date: Thu, 11 Jan 2024 09:38:36 -0600 Subject: [Users] meeting minutes for 2024-01-11 In-Reply-To: References: <20240107161926.06c89a94@fdea4908> <20240110145157.792f8835@ekohaes8> Message-ID: <20240111093836.1d57b38e@ekohaes8> Present: Roland, Peter, Steve, Leo, Andya, Sam, Samuel, Xinyue, Zach ET release: * ET release manager search for 2024_05: Steve (main), Roland (asst) * Peter will update TOV gallery example * Steve found that BNS example differs in new release, Roland will try and run on his workstation to verify Simfactory issues: * Steve has trouble getting simfactory to work on db1 for submission, it ignores sourcebasedir Open tickets: * https://bitbucket.org/einsteintoolkit/tickets/issues/2770 Roland will report issue to ADIOS2 * https://bitbucket.org/einsteintoolkit/tickets/issues/2771 Roland has been in contact with Wolfgang and Michal, they have implemented a similar fix in SGRID's master branch and Roland will backport * https://bitbucket.org/einsteintoolkit/tickets/issues/2520 Peter will re-run TOV example with updated parameters to see if there are visible changes Chapter on ET in Springer book: * Peter and Stefan Rosswog are adding SphincsBSSN code * Leo, Sam, Steve volunteer for ET section, will try and coordinate with Peter * will create skeleton for chapter, add division of space for codes * TODO: check if we need to describe BSSN codes * TODO: Roland to periodically poke * TODO: Roland to see if GRhydro authors can contribute Code changes policy * Samuel asked about how larger changes to contributed code are handled * Roland said that this is effectively up to the authors. The ET is conservative with changes to release branches that should be limited to obvious important bug fixes * For code changes the ET asks that all changes are reviewed but that does to have to be in the ET ticket system and could be code internal * Sam points out that changes that require changing parameter files need to have a deprecation warning for one release before they can be made 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 . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rhaas at illinois.edu Mon Jan 15 09:51:54 2024 From: rhaas at illinois.edu (Roland Haas) Date: Mon, 15 Jan 2024 09:51:54 -0600 Subject: [Users] Fw: PhD fellowships Message-ID: <20240115095154.43e57196@ae4f88e8> Begin forwarded message: Date: Mon, 15 Jan 2024 14:23:18 +0100 From: Enrico Barausse To: Enrico Barausse Subject: PhD fellowships Dear Colleagues please find below the link to a call for applications to our PhD program, in case you know of potentially interested students https://hyperspace.uni-frankfurt.de/2024/01/15/phd-fellowships-at-sissa-italy/ best regards Enrico Barausse From rhaas at illinois.edu Mon Jan 15 15:18:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 15 Jan 2024 15:18:01 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers From schnetter at gmail.com Wed Jan 17 08:53:10 2024 From: schnetter at gmail.com (Erik Schnetter) Date: Wed, 17 Jan 2024 09:53:10 -0500 Subject: [Users] Status of support for multiple floating point precisions in Carpet? In-Reply-To: References: Message-ID: Erik In principle both CCTK_REAL4 and CCTK_REAL8 should be supported. CCTK_REAL16 never worked well because compilers disagree about its layout and size. (Integer types other than CCTK_INT4 should also be supported.) To reduce compile time we then added the flags to disable support for some of these types. It might be that this has bit-rotted and that some newer code doesn't support CCTK_REAL4. It should be "straightforward but tedious" to correct this. I will have a brief look but might not have the time to correct all problems. -erik On Wed, Jan 17, 2024 at 9:41?AM Erik Keoni Wessel wrote: > > Hi, > I'm currently working on a thorn development project where it would be helpful to be able to have a mix of single-precision grid functions and double-precision grid functions (a very unusual need, I know). > > When I had my thorn allocate a grid function of type CCTK_REAL4, I got a message upon running my configurations that I needed to enable support for this type in Carpet. After reading through the Carpet documentation and then digging deep into the source code for CarpetLib, I discovered that there seem to be flags to compile Carpet with support for different types. I passed -DCARPET_ALL_REAL in as part of CPPFLAGS in my optionlist, but attempting to compile with other real types leads to compile-time errors about undefined functions: apparently headers for prolongation functions for all the types are generated, but somehow the corresponding definitions aren't being be linked correctly. > > I'm not sure what is going wrong, but I am also unable to find any examples of how support for other types is supposed to be enabled, so I am unsure if I am doing this right. > > So my question is: what is the status of support for grid functions of types besides CCTK_REAL8 in Carpet? Does this feature work, and if so, how can I enable support for all Cactus-supported real types in Carpet? > > Cheers, > > ? Erik Wessel > Department of Physics > University of Arizona > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/ From bruno.giacomazzo at unimib.it Wed Jan 17 09:44:07 2024 From: bruno.giacomazzo at unimib.it (Bruno Giacomazzo) Date: Wed, 17 Jan 2024 16:44:07 +0100 Subject: [Users] Star disappear from grid In-Reply-To: References: Message-ID: Lorenzo, the perfectly cut away may be due to the fact that you may have had failures in con2prim on the finest levels (and maybe points got set to atmosphere), but the coarser levels were not computed yet. Your standard output reports indeed errors in c2p. You use 6 refinement levels and therefore all levels are at the same time every 2^(6-1)=32 iterations. At iteration 4 only the 3 most inner levels would be at the same. I would increase the resolution since your finest grid is using a resolution of 12/2^5 = 0.375 so that you have a resolution of at least 0.24 on the finest level (level 5) and check if this solves the problem. Cheers, Bruno Il giorno mer 17 gen 2024 alle ore 15:41 Lorenzo Cipriani < lorenzo.cipriani at graduate.univaq.it> ha scritto: > Dear all, > my name is Lorenzo Cipriani, PhD student at the University of L'Aquila. > > My goal is to simulate a BNS merger using initial data computed from > Lorene and evolved according to the parameter file I have attached. > Cactus reads the initial data correctly, as you can see in the image > "rhoxy_initial.png" but, immediately after, the stars practically disappear > from the grid, perfectly cut away (see image "rhoxy_it4.png"). > > Does anybody have a hint on what might be happening? I have never > encountered a behavior like this. > > Thank you for your assistance, > best regards, > Lorenzo > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users > -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.giacomazzo at unimib.it Wed Jan 17 09:50:30 2024 From: bruno.giacomazzo at unimib.it (Bruno Giacomazzo) Date: Wed, 17 Jan 2024 16:50:30 +0100 Subject: [Users] Einsteintoolkit installation on ubuntu 22.04 failed In-Reply-To: References: Message-ID: I'm seeing the same issue with curl now on my laptop (I didn't have this issue last week), but I can access the link via google chrome. I have attached the script in case it is useful to you. Cheers, Bruno Il giorno mer 17 gen 2024 alle ore 15:41 emmanuel okorie ha scritto: > Hi > I'm Okorie Emmanuel from the department of Computer Science, University of > Jos Nigeria. I got to know about the Einstein Toolkit from a friend doing > Phd in physics from my school, i became curious and wanted to explore > toolkits. However, I have been trying to install Einsteintoolkit on my > Ubuntu 22.04 machine for some time now but have not succeeded. > > Each time I try I get this message curl: (28) SSL connection timeout > and when I visit > https://raw.githubusercontent.com/gridaphobe/CRL/ET_2023_11/GetComponents > the page does not load. here is the screenshot of the experience from my > ubuntu terminal > > [image: Screenshot from 2023-12-20 05-30-47.png] > > I'm really frustrated at this point. > > Please can anyone tell me what I'm doing wrong? or any other alternative? > of installing toolkits on my machine. I'm using this guild for installation > > https://einsteintoolkit.org/download.html > > curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/ET_2023_11/GetComponents > chmod a+x GetComponents > ./GetComponents --parallel https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2023_11/einsteintoolkit.th > > > Below is the screenshot of my experience > [image: Screenshot from 2023-12-15 11-28-16.png] > > > I hope someone can help me out > Thanks and regards > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users > -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2023-12-20 05-30-47.png Type: image/png Size: 27543 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2023-12-15 11-28-16.png Type: image/png Size: 96351 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GetComponents Type: application/octet-stream Size: 100495 bytes Desc: not available URL: From rhaas at illinois.edu Wed Jan 17 10:56:05 2024 From: rhaas at illinois.edu (Roland Haas) Date: Wed, 17 Jan 2024 10:56:05 -0600 Subject: [Users] Questions on the installation of ET in Linux system In-Reply-To: <4f5f9447.6e0b4.18c86bc786a.Coremail.chenzhiwei171@mails.ucas.ac.cn> References: <4f5f9447.6e0b4.18c86bc786a.Coremail.chenzhiwei171@mails.ucas.ac.cn> Message-ID: <20240117105605.1b3eb6db@ekohaes8> Hello Zhiwei Chen, Sorry for the delay in responding, your email got hold up for moderator approval. Based on the error message (ld reporting incorrect options), my guess is that you (or something else) either added a line: LD = ld or have an environment variable LD set that points to that ld. However for the Einstein Toolkit LD is actually the compiler wrapper (g++ usually) that used to at the link stage. If you added a LD line to your options list, then I would remove it (since it is not actually needed, the ET will pick the value of CXX as a default). If there is an environment variable set (see the output of "env | grep LD") then you can use (bash syntax): unset LD before compiling the code to remove it (this can be automated in the "envsetup = ..." line(s) in the machine definition file, but I'd first try manually to see if this helps). Yours, Roland > Dear Einstein Toolkit group, > > I am wirting to ask a question on the installation of ET. I have > successfully configured simfactory in my workstation. When I tried to > build the Einstein Toolkit with > > > >>> simfactory/bin/sim build -j2 --thornlist > >>> manifest/einsteintoolkit.th > > > > > ,there is something wrong. > > The build procedure has ran to the stage of : > > > > > >>> Creating cactus_sim in /home/gw_czw/et/Cactus/exe from > >>> EinsteinAnalysis/ADMAnalysis EinsteinBas > Base EinsteinBase/ADMCoupling Llama/ADMDerivatives > EinsteinBase/ADMMacros EinsteinAnalysis/ADMM umerical/AEILocalInterp > EinsteinAnalysis/AHFinder EinsteinAnalysis/AHFinderDirect > ExternalLibra BLAS WVUThorns/Baikal WVUThorns/BaikalVacuum > CactusBase/Boundary CTThorns/CT_Analytic CTThorns/ ltiLevel > EinsteinAnalysis/CalcK Carpet/Carpet Carpet/CarpetEvolutionMask > Carpet/CarpetIOASCII C /CarpetIOBasic Carpet/CarpetIOHDF5 > Carpet/CarpetIOScalar Carpet/CarpetIntegrateTest Carpet/Carp erp > Carpet/CarpetInterp2 Carpet/CarpetLib Carpet/CarpetMask > Carpet/CarpetProlongateTest Carpet/ tReduce Carpet/CarpetRegrid > Carpet/CarpetRegrid2 Carpet/CarpetRegridTest Carpet/CarpetSlab Carp > rpetTracker CactusBase/CartGrid3D CactusNumerical/Cartoon2D > EinsteinBase/Constants WVUThorns/Co _to_HydroBase > CactusBase/CoordBase EinsteinBase/CoordGauge Llama/Coordinates > Llama/CoordinatesS ry Carpet/CycleClock CactusExamples/DemoInterp > CactusNumerical/Dissipation EinsteinInitialData/ rtedBHIVP > EinsteinAnalysis/EHFinder EinsteinBase/EOS_Base > EinsteinEOS/EOS_Hybrid EinsteinEOS/EO alFluid EinsteinEOS/EOS_Omni > EinsteinEOS/EOS_Polytrope EinsteinExact/EinsteinExact_Test CactusE > ic/EllBase CactusElliptic/EllSOR EinsteinInitialData/Exact > EinsteinAnalysis/Extract ExternalLib s/FFTW3 > EinsteinInitialData/FLRWSolver WVUThorns/FishboneMoncriefID > CactusExamples/FleshInfo Ca tils/Formaline CactusBase/Fortran > EinsteinEvolve/GRHydro EinsteinEvolve/GRHydro_InitData Extern > raries/GSL EinsteinExact/GaugeWave KrancNumericalTools/GenericFD > WVUThorns/GiRaFFE WVUThorns/Gi _to_HydroBase WVUThorns/GiRaFFEfood > Llama/GlobalDerivative ExternalLibraries/HDF5 CactusConnect D > CactusConnect/HTTPDExtra CactusExamples/HelloWorld > Carpet/HighOrderWaveTest EinsteinBase/Hydr > EinsteinAnalysis/Hydro_Analysis > EinsteinInitialData/Hydro_InitExcision EinsteinInitialData/Hyd SID > EinsteinInitialData/IDAnalyticBH EinsteinInitialData/IDAxiBrillBH > EinsteinInitialData/IDAxi illBH EinsteinInitialData/IDBrillData > EinsteinInitialData/IDConstraintViolate EinsteinInitialDa FileADM > EinsteinInitialData/IDLinearWaves CactusWave/IDScalarWave > CactusWave/IDScalarWaveC Cact e/IDScalarWaveCXX > CactusWave/IDScalarWaveElliptic CactusExamples/IDWaveMoL > WVUThorns/ID_convert RaFFE WVUThorns/ID_converter_ILGRMHD > CactusBase/IOASCII CactusBase/IOBasic CactusPUGHIO/IOHDF5 > sPUGHIO/IOHDF5Util CactusIO/IOJpeg CactusBase/IOUtil > WVUThorns/IllinoisGRMHD CactusBase/InitBas tusNumerical/InterpToArray > Llama/Interpolate2 EinsteinExact/KerrSchild ExternalLibraries/LAPACK > rnalLibraries/LORENE Lean/LeanBSSNMoL Llama/LlamaWaveToy > CactusNumerical/LocalInterp CactusNume /LocalInterp2 > CactusNumerical/LocalReduce Carpet/LoopControl > McLachlan/ML_ADMConstraints McLach L_ADMQuantities McLachlan/ML_BSSN > McLachlan/ML_BSSN_Helper McLachlan/ML_BSSN_Test McLachlan/ML_ > McLachlan/ML_CCZ4_Helper McLachlan/ML_CCZ4_Test McLachlan/ML_WaveToy > McLachlan/ML_WaveToy_Test nalLibraries/MPI CactusUtils/MemSpeed > EinsteinInitialData/Meudon_Bin_BH EinsteinInitialData/Meu in_NS > EinsteinInitialData/Meudon_Mag_NS EinsteinExact/Minkowski > CactusNumerical/MoL EinsteinExa difiedSchwarzschildBL > EinsteinAnalysis/Multipole Lean/NPScalars Proca/NPScalars_Proca > EinsteinI lData/NRPyEllipticET CactusUtils/NaNCatcher > CactusUtils/NaNChecker EinsteinEvolve/NewRad Cactus /Nice > EinsteinInitialData/NoExcision CactusUtils/NoMPI > CactusNumerical/Noise CactusNumerical/No ITTNullCode/NullConstr > PITTNullCode/NullDecomp PITTNullCode/NullEvolve > PITTNullCode/NullExact P llCode/NullGrid PITTNullCode/NullInterp > PITTNullCode/NullNews PITTNullCode/NullPsiInt PITTNullC ullSHRExtract > PITTNullCode/NullVars ExternalLibraries/OpenSSL > EinsteinAnalysis/Outflow External ries/PAPI CactusPUGH/PUGH > CactusPUGH/PUGHInterp CactusPUGH/PUGHReduce CactusPUGH/PUGHSlab Cactu > rical/Periodic Carpet/PeriodicCarpet CactusExamples/Poisson > Proca/ProcaBase Proca/ProcaEvolve P Proca_simpleID > EinsteinAnalysis/PunctureTracker EinsteinAnalysis/QuasiLocalMeasures > EinsteinIni ata/ReadInterpolate Carpet/ReductionTest > Carpet/ReductionTest2 Carpet/ReductionTest3 CactusNume > /ReflectionSymmetry Carpet/RegridSyncTest > EinsteinInitialData/RotatingDBHIVP CactusNumerical/Ro gSymmetry180 > CactusNumerical/RotatingSymmetry90 CactusExamples/SampleBoundary > CactusExamples/Sa O Scalar/ScalarBase Scalar/ScalarEvolve > Scalar/ScalarInit WVUThorns/Seed_Magnetic_Fields WVUTho > iagnostics/Seed_Magnetic_Fields_BNS > EinsteinUtils/SetMask_SphericalSurface EinsteinExact/Shifte eWave > WVUThorns/ShiftedKerrSchild CactusNumerical/Slab > CactusNumerical/SlabTest CactusConnect/S CactusNumerical/SpaceMask > PITTNullCode/SphericalHarmonicDecomp PITTNullCode/SphericalHarmonicR > PITTNullCode/SphericalHarmonicReconGen > CactusNumerical/SphericalSurface EinsteinBase/StaticConf > CactusNumerical/SummationByParts CactusBase/SymBase > CactusUtils/SystemStatistics CactusUtils/S Topology > CactusElliptic/TATelliptic EinsteinUtils/TGRtensor > EinsteinInitialData/TOVSolver Cactu rical/TensorTypes > CactusUtils/TerminationTrigger CactusTest/TestArrays > Carpet/TestCarpetGridInf tusTest/TestComplex > CactusTest/TestCoordinates CactusTest/TestFortranCrayPointers > CactusTest/Te tranDependencies1 CactusTest/TestFortranDependencies2 > CactusTest/TestFpointerNULL CactusTest/Te eF90 > CactusTest/TestGlobalReduce CactusTest/TestInclude1 > CactusTest/TestInclude2 CactusNumerica tLocalInterp2 > CactusNumerical/TestLocalReduce CactusTest/TestLoop > Carpet/TestLoopControl Cactus TestMath CactusTest/TestMoL > CactusTest/TestPar CactusTest/TestReadWrite CactusTest/TestReduce C > Test/TestSchedule CactusTest/TestStrings CactusTest/TestTable > CactusTest/TestTimers CactusTest/ ypes CactusBase/Time > CactusExamples/TimerInfo CactusUtils/TimerReport Carpet/Timers > EinsteinBas nuBase CactusUtils/Trigger > EinsteinInitialData/TwoPunctures Scalar/TwoPunctures_BBHSF Proca/Two > ures_KerrProca EinsteinExact/Vaidya2 CactusUtils/Vectors > WVUThorns_Diagnostics/VolumeIntegrals_ > WVUThorns_Diagnostics/VolumeIntegrals_vacuum CactusUtils/WatchDog > CactusWave/WaveBinarySource /WaveExtractL CactusExamples/WaveMoL > CactusExamples/WaveToy1DF77 CactusExamples/WaveToy2DF77 Ca > ave/WaveToyC CactusWave/WaveToyCXX CactusWave/WaveToyExtra > CactusWave/WaveToyF77 CactusWave/Wav 90 CactusWave/WaveToyFreeF90 > EinsteinAnalysis/WeylScal4 ExternalLibraries/hwloc ExternalLibrari > bjpeg WVUThorns_Diagnostics/particle_tracerET > ExternalLibraries/pthreads WVUThorns_Diagnostics/ bPoynET > ExternalLibraries/zlib > > > > > The report gave error: > > >>> /home/gw_czw/anaconda3/bin/x86_64-conda-linux-gnu-ld: > >>> unrecognized option '-Wall' > /home/gw_czw/anaconda3/bin/x86_64-conda-linux-gnu-ld: use the --help > option for usage informati make[1]: *** > [/home/gw_czw/et/Cactus/lib/make/make.configuration:150: > /home/gw_czw/et/Cactus/ex tus_sim] Error 1 make: *** [Makefile:265: > sim] Error 2 > > > > > So what does this "-wall" mean? I can not find such option in > theeinsteintoolkit.th file. > > > > > Thanks very much if you could help me solve this problem! > > > > > Yours, > > Zhiwei Chen > > -- 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rhaas at illinois.edu Wed Jan 17 10:59:31 2024 From: rhaas at illinois.edu (Roland Haas) Date: Wed, 17 Jan 2024 10:59:31 -0600 Subject: [Users] Einsteintoolkit installation on ubuntu 22.04 failed In-Reply-To: References: Message-ID: <20240117105931.2f19d632@ekohaes8> Hello all, This seems more like a GitHub issue really. Though, a workaround would still be very nice of course. Is there a way to add verbosity to the curl call (add --verbose I guess)? Otherwise, I would also give wget a try to see if it is able to access github. Finally, maybe try add a http user agent to curl (maybe github blocks curl...): curl --user-agent Mozilla ... It will be a while before I can test this with a Ubuntu VM. Yours, Roland > I'm seeing the same issue with curl now on my laptop (I didn't have this > issue last week), but I can access the link via google chrome. I have > attached the script in case it is useful to you. > > Cheers, > Bruno > > > Il giorno mer 17 gen 2024 alle ore 15:41 emmanuel okorie > ha scritto: > > > Hi > > I'm Okorie Emmanuel from the department of Computer Science, University of > > Jos Nigeria. I got to know about the Einstein Toolkit from a friend doing > > Phd in physics from my school, i became curious and wanted to explore > > toolkits. However, I have been trying to install Einsteintoolkit on my > > Ubuntu 22.04 machine for some time now but have not succeeded. > > > > Each time I try I get this message curl: (28) SSL connection timeout > > and when I visit > > https://urldefense.com/v3/__https://raw.githubusercontent.com/gridaphobe/CRL/ET_2023_11/GetComponents__;!!DZ3fjg!5KOr2SYuXBQwCeFEt6p-b5dwFXmcUoEa5-9DgiQcpgqdRjgfDd_renRjn1gsvCqzQx-OIPbCy30mUnld5SmHmeo-teJ-EA$ > > the page does not load. here is the screenshot of the experience from my > > ubuntu terminal > > > > [image: Screenshot from 2023-12-20 05-30-47.png] > > > > I'm really frustrated at this point. > > > > Please can anyone tell me what I'm doing wrong? or any other alternative? > > of installing toolkits on my machine. I'm using this guild for installation > > > > https://urldefense.com/v3/__https://einsteintoolkit.org/download.html__;!!DZ3fjg!5KOr2SYuXBQwCeFEt6p-b5dwFXmcUoEa5-9DgiQcpgqdRjgfDd_renRjn1gsvCqzQx-OIPbCy30mUnld5SmHmepsxH__pw$ > > > > curl -kLO https://urldefense.com/v3/__https://raw.githubusercontent.com/gridaphobe/CRL/ET_2023_11/GetComponents__;!!DZ3fjg!5KOr2SYuXBQwCeFEt6p-b5dwFXmcUoEa5-9DgiQcpgqdRjgfDd_renRjn1gsvCqzQx-OIPbCy30mUnld5SmHmeo-teJ-EA$ > > chmod a+x GetComponents > > ./GetComponents --parallel https://urldefense.com/v3/__https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2023_11/einsteintoolkit.th__;!!DZ3fjg!5KOr2SYuXBQwCeFEt6p-b5dwFXmcUoEa5-9DgiQcpgqdRjgfDd_renRjn1gsvCqzQx-OIPbCy30mUnld5SmHmepr584Tnw$ > > > > > > Below is the screenshot of my experience > > [image: Screenshot from 2023-12-15 11-28-16.png] > > > > > > I hope someone can help me out > > Thanks and regards > > _______________________________________________ > > Users mailing list > > Users at einsteintoolkit.org > > https://urldefense.com/v3/__http://lists.einsteintoolkit.org/mailman/listinfo/users__;!!DZ3fjg!5KOr2SYuXBQwCeFEt6p-b5dwFXmcUoEa5-9DgiQcpgqdRjgfDd_renRjn1gsvCqzQx-OIPbCy30mUnld5SmHmeoiy33OHA$ > > > > -- 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rhaas at illinois.edu Wed Jan 17 17:15:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 17 Jan 2024 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers From schnetter at gmail.com Wed Jan 17 18:52:47 2024 From: schnetter at gmail.com (Erik Schnetter) Date: Wed, 17 Jan 2024 19:52:47 -0500 Subject: [Users] Status of support for multiple floating point precisions in Carpet? In-Reply-To: References: Message-ID: Erik The attached patch should correct the problems you're seeing. Please let me know if this works; if so, we will need to create a proper pull request. -erik On Wed, Jan 17, 2024 at 9:53?AM Erik Schnetter wrote: > > Erik > > In principle both CCTK_REAL4 and CCTK_REAL8 should be supported. > CCTK_REAL16 never worked well because compilers disagree about its > layout and size. > > (Integer types other than CCTK_INT4 should also be supported.) > > To reduce compile time we then added the flags to disable support for > some of these types. It might be that this has bit-rotted and that > some newer code doesn't support CCTK_REAL4. It should be > "straightforward but tedious" to correct this. > > I will have a brief look but might not have the time to correct all problems. > > -erik > > On Wed, Jan 17, 2024 at 9:41?AM Erik Keoni Wessel wrote: > > > > Hi, > > I'm currently working on a thorn development project where it would be helpful to be able to have a mix of single-precision grid functions and double-precision grid functions (a very unusual need, I know). > > > > When I had my thorn allocate a grid function of type CCTK_REAL4, I got a message upon running my configurations that I needed to enable support for this type in Carpet. After reading through the Carpet documentation and then digging deep into the source code for CarpetLib, I discovered that there seem to be flags to compile Carpet with support for different types. I passed -DCARPET_ALL_REAL in as part of CPPFLAGS in my optionlist, but attempting to compile with other real types leads to compile-time errors about undefined functions: apparently headers for prolongation functions for all the types are generated, but somehow the corresponding definitions aren't being be linked correctly. > > > > I'm not sure what is going wrong, but I am also unable to find any examples of how support for other types is supposed to be enabled, so I am unsure if I am doing this right. > > > > So my question is: what is the status of support for grid functions of types besides CCTK_REAL8 in Carpet? Does this feature work, and if so, how can I enable support for all Cactus-supported real types in Carpet? > > > > Cheers, > > > > ? Erik Wessel > > Department of Physics > > University of Arizona > > _______________________________________________ > > Users mailing list > > Users at einsteintoolkit.org > > http://lists.einsteintoolkit.org/mailman/listinfo/users > > > > -- > Erik Schnetter > http://www.perimeterinstitute.ca/personal/eschnetter/ -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/ -------------- next part -------------- A non-text attachment was scrubbed... Name: carpet-real4.diff Type: application/octet-stream Size: 32080 bytes Desc: not available URL: From lorenzo.cipriani at graduate.univaq.it Thu Jan 18 07:55:06 2024 From: lorenzo.cipriani at graduate.univaq.it (Lorenzo Cipriani) Date: Thu, 18 Jan 2024 13:55:06 +0000 Subject: [Users] R: Star disappear from grid In-Reply-To: References: Message-ID: Dear Bruno, I increased the resolution so that the finest level now has a resolution of 7/2^5 = 0.21875 using a smaller coarse grid, but the output remains unchanged. Please let me know your thoughts on this! Best, Lorenzo ________________________________ Da: Bruno Giacomazzo Inviato: mercoled? 17 gennaio 2024 16:44 A: Lorenzo Cipriani Cc: users at einsteintoolkit.org Oggetto: Re: [Users] Star disappear from grid Lorenzo, the perfectly cut away may be due to the fact that you may have had failures in con2prim on the finest levels (and maybe points got set to atmosphere), but the coarser levels were not computed yet. Your standard output reports indeed errors in c2p. You use 6 refinement levels and therefore all levels are at the same time every 2^(6-1)=32 iterations. At iteration 4 only the 3 most inner levels would be at the same. I would increase the resolution since your finest grid is using a resolution of 12/2^5 = 0.375 so that you have a resolution of at least 0.24 on the finest level (level 5) and check if this solves the problem. Cheers, Bruno Il giorno mer 17 gen 2024 alle ore 15:41 Lorenzo Cipriani > ha scritto: Dear all, my name is Lorenzo Cipriani, PhD student at the University of L'Aquila. My goal is to simulate a BNS merger using initial data computed from Lorene and evolved according to the parameter file I have attached. Cactus reads the initial data correctly, as you can see in the image "rhoxy_initial.png" but, immediately after, the stars practically disappear from the grid, perfectly cut away (see image "rhoxy_it4.png"). Does anybody have a hint on what might be happening? I have never encountered a behavior like this. Thank you for your assistance, best regards, Lorenzo _______________________________________________ Users mailing list Users at einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rho_xy.png Type: image/png Size: 12803 bytes Desc: rho_xy.png URL: From bruno.giacomazzo at unimib.it Thu Jan 18 08:13:09 2024 From: bruno.giacomazzo at unimib.it (Bruno Giacomazzo) Date: Thu, 18 Jan 2024 15:13:09 +0100 Subject: [Users] Star disappear from grid In-Reply-To: References: Message-ID: Lorenzo, I opened the hdf5 file you sent me and I indeed see the same problem (I attached a couple of snapshots). So it is not a problem of resolution. Did you check that hydro quantities and spacetime variables are initialized correctly (just in case there is a problem with the initial data file)? Cheers, Bruno Il giorno gio 18 gen 2024 alle ore 14:55 Lorenzo Cipriani < lorenzo.cipriani at graduate.univaq.it> ha scritto: > Dear Bruno, > > I increased the resolution so that the finest level now has a resolution > of 7/2^5 = 0.21875 using a smaller coarse grid, but the output remains > unchanged. > > Please let me know your thoughts on this! > > Best, > Lorenzo > > ------------------------------ > *Da:* Bruno Giacomazzo > *Inviato:* mercoled? 17 gennaio 2024 16:44 > *A:* Lorenzo Cipriani > *Cc:* users at einsteintoolkit.org > *Oggetto:* Re: [Users] Star disappear from grid > > Lorenzo, > the perfectly cut away may be due to the fact that you may have had > failures in con2prim on the finest levels (and maybe points got set to > atmosphere), but the coarser levels were not computed yet. Your standard > output reports indeed errors in c2p. You use 6 refinement levels and > therefore all levels are at the same time every 2^(6-1)=32 iterations. At > iteration 4 only the 3 most inner levels would be at the same. > > I would increase the resolution since your finest grid is using a > resolution of 12/2^5 = 0.375 so that you have a resolution of at least 0.24 > on the finest level (level 5) and check if this solves the problem. > > Cheers, > Bruno > > > Il giorno mer 17 gen 2024 alle ore 15:41 Lorenzo Cipriani < > lorenzo.cipriani at graduate.univaq.it> ha scritto: > > Dear all, > my name is Lorenzo Cipriani, PhD student at the University of L'Aquila. > > My goal is to simulate a BNS merger using initial data computed from > Lorene and evolved according to the parameter file I have attached. > Cactus reads the initial data correctly, as you can see in the image > "rhoxy_initial.png" but, immediately after, the stars practically disappear > from the grid, perfectly cut away (see image "rhoxy_it4.png"). > > Does anybody have a hint on what might be happening? I have never > encountered a behavior like this. > > Thank you for your assistance, > best regards, > Lorenzo > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users > > > > -- > > Prof. Bruno Giacomazzo > Department of Physics > University of Milano-Bicocca > Piazza della Scienza 3 > 20126 Milano > Italy > > email: bruno.giacomazzo at unimib.it > phone: (+39) 02 6448 2321 > web: http://www.brunogiacomazzo.org > > --------------------------------------------------------------------- > There are only 10 types of people in the world: > Those who understand binary, and those who don't > ---------------------------------------------------------------------- > -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: movie_965x905_0001.jpeg Type: image/jpeg Size: 44582 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: movie_965x905_0000.jpeg Type: image/jpeg Size: 46586 bytes Desc: not available URL: From sbrandt at cct.lsu.edu Thu Jan 18 09:47:49 2024 From: sbrandt at cct.lsu.edu (Steven Brandt) Date: Thu, 18 Jan 2024 09:47:49 -0600 Subject: [Users] meeting minutes for 2024-01-18 Message-ID: Present: Bing-Ran HE, Steve, Roland, Lihaichang, Sam Cupp, shenfei, Zach, Leo Chair: Roland Minutes: Steve Need to have a release schedule List of updates for the next release: ??? Reprimand - is there a use case? ??? Gallery examples for ID readers FUKA, Sgrid, Canuda ??? TOV solver based on Grhayl, tabulated EOS builtin ??? New Grhayl-based MHD thorns - Gallery example? ??? New tabulated eqn state ??? Baikal updates Bing asked about initial data ??? he did not feel LORENE was friendly ??? Roland pointed him to FUKA and Sgrid http://einsteintoolkit.org/thornguide/ExternalLibraries/SGRID/documentation.html http://einsteintoolkit.org/thornguide/Fuka/KadathImporter/documentation.html Roland will try and replicate failure of BNS Trying again to get the check from SPEC No unanswered questions on the email list Open tickets: ??????? 2772 Kadath - linking issue on systems with mkl ??? and 2755 POWER - Doesn't compute angular momentum correctly (wrong formula) From lorenzo.cipriani at graduate.univaq.it Thu Jan 18 17:30:00 2024 From: lorenzo.cipriani at graduate.univaq.it (Lorenzo Cipriani) Date: Thu, 18 Jan 2024 23:30:00 +0000 Subject: [Users] R: Star disappear from grid In-Reply-To: References: Message-ID: I noticed that the Hamiltonian constraint violation along the x-axis (y=0, z=0) (in the attached image, taken from the H.xy.h5 file), has a very peculiar shape, aligned with the stars profile. This is very wrong, am I right? So, the problem is either in the EoS, more likely, or Lorene. Lorenzo ________________________________ Da: Bruno Giacomazzo Inviato: gioved? 18 gennaio 2024 15:13 A: Lorenzo Cipriani Cc: users at einsteintoolkit.org Oggetto: Re: [Users] Star disappear from grid Lorenzo, I opened the hdf5 file you sent me and I indeed see the same problem (I attached a couple of snapshots). So it is not a problem of resolution. Did you check that hydro quantities and spacetime variables are initialized correctly (just in case there is a problem with the initial data file)? Cheers, Bruno Il giorno gio 18 gen 2024 alle ore 14:55 Lorenzo Cipriani > ha scritto: Dear Bruno, I increased the resolution so that the finest level now has a resolution of 7/2^5 = 0.21875 using a smaller coarse grid, but the output remains unchanged. Please let me know your thoughts on this! Best, Lorenzo ________________________________ Da: Bruno Giacomazzo > Inviato: mercoled? 17 gennaio 2024 16:44 A: Lorenzo Cipriani > Cc: users at einsteintoolkit.org > Oggetto: Re: [Users] Star disappear from grid Lorenzo, the perfectly cut away may be due to the fact that you may have had failures in con2prim on the finest levels (and maybe points got set to atmosphere), but the coarser levels were not computed yet. Your standard output reports indeed errors in c2p. You use 6 refinement levels and therefore all levels are at the same time every 2^(6-1)=32 iterations. At iteration 4 only the 3 most inner levels would be at the same. I would increase the resolution since your finest grid is using a resolution of 12/2^5 = 0.375 so that you have a resolution of at least 0.24 on the finest level (level 5) and check if this solves the problem. Cheers, Bruno Il giorno mer 17 gen 2024 alle ore 15:41 Lorenzo Cipriani > ha scritto: Dear all, my name is Lorenzo Cipriani, PhD student at the University of L'Aquila. My goal is to simulate a BNS merger using initial data computed from Lorene and evolved according to the parameter file I have attached. Cactus reads the initial data correctly, as you can see in the image "rhoxy_initial.png" but, immediately after, the stars practically disappear from the grid, perfectly cut away (see image "rhoxy_it4.png"). Does anybody have a hint on what might be happening? I have never encountered a behavior like this. Thank you for your assistance, best regards, Lorenzo _______________________________________________ Users mailing list Users at einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ham_constr.png Type: image/png Size: 105506 bytes Desc: ham_constr.png URL: From bozzola.gabriele at gmail.com Thu Jan 18 17:53:28 2024 From: bozzola.gabriele at gmail.com (Gabriele Bozzola) Date: Thu, 18 Jan 2024 15:53:28 -0800 Subject: [Users] R: Star disappear from grid In-Reply-To: References: Message-ID: Dear Lorenzo, It is to be expected that the region with the highest density and gravity is the one with the highest constraint violation. I think that the problem you are seeing is an output one. (Disclaimer, this is my understanding; I might very well be wrong) You have several refinement levels. Different refinement levels evolve at a different pace (determined by your time_refinement_factors, which by default is essentially proportionally to your local dx), and iteration #4 (that you are plotting) is not one where all the refinement levels are synced. My guess is that the stars will appear if you plot iterations 128. You might also be able use kuibit to inspect your HDF5 files and see what refinement levels are in the data. That would be something like: ``` import kuibit print(SimDir("PATH_OF_DATA_FOLDER").gf.xy["rho"][4].available_refinement_levels) ``` Best, Gabriele On Thu, Jan 18, 2024 at 3:30?PM Lorenzo Cipriani < lorenzo.cipriani at graduate.univaq.it> wrote: > I noticed that the Hamiltonian constraint violation along the x-axis (y=0, > z=0) (in the attached image, taken from the H.xy.h5 file), has a very > peculiar shape, aligned with the stars profile. This is very wrong, am I > right? > So, the problem is either in the EoS, more likely, or Lorene. > > Lorenzo > ------------------------------ > *Da:* Bruno Giacomazzo > *Inviato:* gioved? 18 gennaio 2024 15:13 > *A:* Lorenzo Cipriani > *Cc:* users at einsteintoolkit.org > *Oggetto:* Re: [Users] Star disappear from grid > > Lorenzo, > I opened the hdf5 file you sent me and I indeed see the same problem (I > attached a couple of snapshots). So it is not a problem of resolution. Did > you check that hydro quantities and spacetime variables are initialized > correctly (just in case there is a problem with the initial data file)? > > Cheers, > Bruno > > > Il giorno gio 18 gen 2024 alle ore 14:55 Lorenzo Cipriani < > lorenzo.cipriani at graduate.univaq.it> ha scritto: > > Dear Bruno, > > I increased the resolution so that the finest level now has a resolution > of 7/2^5 = 0.21875 using a smaller coarse grid, but the output remains > unchanged. > > Please let me know your thoughts on this! > > Best, > Lorenzo > > ------------------------------ > *Da:* Bruno Giacomazzo > *Inviato:* mercoled? 17 gennaio 2024 16:44 > *A:* Lorenzo Cipriani > *Cc:* users at einsteintoolkit.org > *Oggetto:* Re: [Users] Star disappear from grid > > Lorenzo, > the perfectly cut away may be due to the fact that you may have had > failures in con2prim on the finest levels (and maybe points got set to > atmosphere), but the coarser levels were not computed yet. Your standard > output reports indeed errors in c2p. You use 6 refinement levels and > therefore all levels are at the same time every 2^(6-1)=32 iterations. At > iteration 4 only the 3 most inner levels would be at the same. > > I would increase the resolution since your finest grid is using a > resolution of 12/2^5 = 0.375 so that you have a resolution of at least 0.24 > on the finest level (level 5) and check if this solves the problem. > > Cheers, > Bruno > > > Il giorno mer 17 gen 2024 alle ore 15:41 Lorenzo Cipriani < > lorenzo.cipriani at graduate.univaq.it> ha scritto: > > Dear all, > my name is Lorenzo Cipriani, PhD student at the University of L'Aquila. > > My goal is to simulate a BNS merger using initial data computed from > Lorene and evolved according to the parameter file I have attached. > Cactus reads the initial data correctly, as you can see in the image > "rhoxy_initial.png" but, immediately after, the stars practically disappear > from the grid, perfectly cut away (see image "rhoxy_it4.png"). > > Does anybody have a hint on what might be happening? I have never > encountered a behavior like this. > > Thank you for your assistance, > best regards, > Lorenzo > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users > > > > -- > > Prof. Bruno Giacomazzo > Department of Physics > University of Milano-Bicocca > Piazza della Scienza 3 > 20126 Milano > Italy > > email: bruno.giacomazzo at unimib.it > phone: (+39) 02 6448 2321 > web: http://www.brunogiacomazzo.org > > --------------------------------------------------------------------- > There are only 10 types of people in the world: > Those who understand binary, and those who don't > ---------------------------------------------------------------------- > > > > -- > > Prof. Bruno Giacomazzo > Department of Physics > University of Milano-Bicocca > Piazza della Scienza 3 > 20126 Milano > Italy > > email: bruno.giacomazzo at unimib.it > phone: (+39) 02 6448 2321 > web: http://www.brunogiacomazzo.org > > --------------------------------------------------------------------- > There are only 10 types of people in the world: > Those who understand binary, and those who don't > ---------------------------------------------------------------------- > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schnetter at gmail.com Thu Jan 18 18:54:48 2024 From: schnetter at gmail.com (Erik Schnetter) Date: Thu, 18 Jan 2024 19:54:48 -0500 Subject: [Users] Status of support for multiple floating point precisions in Carpet? In-Reply-To: References: Message-ID: Erik The patch I sent earlier was incomplete. I also realized that setting `-DCARPET_ALL_REAL` does not work. A working version (i.e. a version that can be compiled) is now in the branch `https://bitbucket.org/eschnett/carpet/branch/eschnett/all-types`. -erik On Wed, Jan 17, 2024 at 7:52?PM Erik Schnetter wrote: > > Erik > > The attached patch should correct the problems you're seeing. Please > let me know if this works; if so, we will need to create a proper pull > request. > > -erik > > On Wed, Jan 17, 2024 at 9:53?AM Erik Schnetter wrote: > > > > Erik > > > > In principle both CCTK_REAL4 and CCTK_REAL8 should be supported. > > CCTK_REAL16 never worked well because compilers disagree about its > > layout and size. > > > > (Integer types other than CCTK_INT4 should also be supported.) > > > > To reduce compile time we then added the flags to disable support for > > some of these types. It might be that this has bit-rotted and that > > some newer code doesn't support CCTK_REAL4. It should be > > "straightforward but tedious" to correct this. > > > > I will have a brief look but might not have the time to correct all problems. > > > > -erik > > > > On Wed, Jan 17, 2024 at 9:41?AM Erik Keoni Wessel wrote: > > > > > > Hi, > > > I'm currently working on a thorn development project where it would be helpful to be able to have a mix of single-precision grid functions and double-precision grid functions (a very unusual need, I know). > > > > > > When I had my thorn allocate a grid function of type CCTK_REAL4, I got a message upon running my configurations that I needed to enable support for this type in Carpet. After reading through the Carpet documentation and then digging deep into the source code for CarpetLib, I discovered that there seem to be flags to compile Carpet with support for different types. I passed -DCARPET_ALL_REAL in as part of CPPFLAGS in my optionlist, but attempting to compile with other real types leads to compile-time errors about undefined functions: apparently headers for prolongation functions for all the types are generated, but somehow the corresponding definitions aren't being be linked correctly. > > > > > > I'm not sure what is going wrong, but I am also unable to find any examples of how support for other types is supposed to be enabled, so I am unsure if I am doing this right. > > > > > > So my question is: what is the status of support for grid functions of types besides CCTK_REAL8 in Carpet? Does this feature work, and if so, how can I enable support for all Cactus-supported real types in Carpet? > > > > > > Cheers, > > > > > > ? Erik Wessel > > > Department of Physics > > > University of Arizona > > > _______________________________________________ > > > Users mailing list > > > Users at einsteintoolkit.org > > > http://lists.einsteintoolkit.org/mailman/listinfo/users > > > > > > > > -- > > Erik Schnetter > > http://www.perimeterinstitute.ca/personal/eschnetter/ > > > > -- > Erik Schnetter > http://www.perimeterinstitute.ca/personal/eschnetter/ -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/ From lorenzo.cipriani at graduate.univaq.it Fri Jan 19 02:00:00 2024 From: lorenzo.cipriani at graduate.univaq.it (Lorenzo Cipriani) Date: Fri, 19 Jan 2024 08:00:00 +0000 Subject: [Users] R: R: Star disappear from grid In-Reply-To: References: Message-ID: Hi Gabriele, indeed, at iteration 4 there are only two refinement levels available (5th and 6th ), but between these first iterations all matter disappears from the grid. The simulation never reaches the point in which they are all synchronized. Lorenzo ________________________________ Da: Gabriele Bozzola Inviato: venerd? 19 gennaio 2024 00:53 A: Lorenzo Cipriani Cc: Bruno Giacomazzo ; users at einsteintoolkit.org Oggetto: Re: [Users] R: Star disappear from grid Dear Lorenzo, It is to be expected that the region with the highest density and gravity is the one with the highest constraint violation. I think that the problem you are seeing is an output one. (Disclaimer, this is my understanding; I might very well be wrong) You have several refinement levels. Different refinement levels evolve at a different pace (determined by your time_refinement_factors, which by default is essentially proportionally to your local dx), and iteration #4 (that you are plotting) is not one where all the refinement levels are synced. My guess is that the stars will appear if you plot iterations 128. You might also be able use kuibit to inspect your HDF5 files and see what refinement levels are in the data. That would be something like: ``` import kuibit print(SimDir("PATH_OF_DATA_FOLDER").gf.xy["rho"][4].available_refinement_levels) ``` Best, Gabriele On Thu, Jan 18, 2024 at 3:30?PM Lorenzo Cipriani > wrote: I noticed that the Hamiltonian constraint violation along the x-axis (y=0, z=0) (in the attached image, taken from the H.xy.h5 file), has a very peculiar shape, aligned with the stars profile. This is very wrong, am I right? So, the problem is either in the EoS, more likely, or Lorene. Lorenzo ________________________________ Da: Bruno Giacomazzo > Inviato: gioved? 18 gennaio 2024 15:13 A: Lorenzo Cipriani > Cc: users at einsteintoolkit.org > Oggetto: Re: [Users] Star disappear from grid Lorenzo, I opened the hdf5 file you sent me and I indeed see the same problem (I attached a couple of snapshots). So it is not a problem of resolution. Did you check that hydro quantities and spacetime variables are initialized correctly (just in case there is a problem with the initial data file)? Cheers, Bruno Il giorno gio 18 gen 2024 alle ore 14:55 Lorenzo Cipriani > ha scritto: Dear Bruno, I increased the resolution so that the finest level now has a resolution of 7/2^5 = 0.21875 using a smaller coarse grid, but the output remains unchanged. Please let me know your thoughts on this! Best, Lorenzo ________________________________ Da: Bruno Giacomazzo > Inviato: mercoled? 17 gennaio 2024 16:44 A: Lorenzo Cipriani > Cc: users at einsteintoolkit.org > Oggetto: Re: [Users] Star disappear from grid Lorenzo, the perfectly cut away may be due to the fact that you may have had failures in con2prim on the finest levels (and maybe points got set to atmosphere), but the coarser levels were not computed yet. Your standard output reports indeed errors in c2p. You use 6 refinement levels and therefore all levels are at the same time every 2^(6-1)=32 iterations. At iteration 4 only the 3 most inner levels would be at the same. I would increase the resolution since your finest grid is using a resolution of 12/2^5 = 0.375 so that you have a resolution of at least 0.24 on the finest level (level 5) and check if this solves the problem. Cheers, Bruno Il giorno mer 17 gen 2024 alle ore 15:41 Lorenzo Cipriani > ha scritto: Dear all, my name is Lorenzo Cipriani, PhD student at the University of L'Aquila. My goal is to simulate a BNS merger using initial data computed from Lorene and evolved according to the parameter file I have attached. Cactus reads the initial data correctly, as you can see in the image "rhoxy_initial.png" but, immediately after, the stars practically disappear from the grid, perfectly cut away (see image "rhoxy_it4.png"). Does anybody have a hint on what might be happening? I have never encountered a behavior like this. Thank you for your assistance, best regards, Lorenzo _______________________________________________ Users mailing list Users at einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- _______________________________________________ Users mailing list Users at einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.giacomazzo at unimib.it Mon Jan 22 05:02:21 2024 From: bruno.giacomazzo at unimib.it (Bruno Giacomazzo) Date: Mon, 22 Jan 2024 12:02:21 +0100 Subject: [Users] Tenured professorship in Astrophysics at the University of Milano-Bicocca (Italy) In-Reply-To: References: Message-ID: The University of Milano-Bicocca (Milan, Italy) will be opening a tenured professorship in astrophysics, with a focus on gravitational-wave data analysis and exploitation. With this notice, we invite expressions of interest from potential candidates. Milano-Bicocca hosts a large group in gravitational astronomy, with activities covering all bands of the gravitational-wave spectrum and the related experiments (LIGO/Virgo, LISA, ET, PTA). Faculty members with matching interests include Bortolas, Colpi, Dotti, Gerosa, Giacomazzo, and Sesana. The group hosts two large ERC grants and currently counts about 10 PhD students and 15 postdocs. We are part of a wider astrophysics unit at Milano-Bicocca (with activities in large-scale structures and experimental cosmology) as well as a large Physics department with ~70 faculty members. We are targeting the opening of a faculty position on a timescale of a few months, with a prospective starting date in the early fall of 2024. Onboarding will be at the associate professor level (?professore associato? in the Italian system), which is a tenured appointment. Formal application requirements include holding either the Italian national habilitation (ASN) or a comparable position abroad for at least 3 years. We are happy to assist potential candidates with their ASN application. Current strategic interests include the development of gravitational-wave data-analysis pipelines for the LISA space mission. At the same time, we are open to all strong candidates willing to bring their ambitious research programs in relativistic astrophysics and/or gravitational-wave astronomy to Milan. Interested applicants are encouraged to send their CVs and a short cover letter to bruno.giacomazzo at unimib.it by February 15th, 2024. The CV should include the names and email addresses of three referees who might be approached for references. -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Mon Jan 22 15:18:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 22 Jan 2024 15:18:01 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers From rhaas at illinois.edu Wed Jan 24 17:15:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 24 Jan 2024 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers From eloisa.bentivegna at protonmail.com Wed Jan 24 17:26:50 2024 From: eloisa.bentivegna at protonmail.com (eloisa.bentivegna) Date: Wed, 24 Jan 2024 23:26:50 +0000 Subject: [Users] Summer 2024 internships at IBM Research Message-ID: Hi everyone, I would like to share the opportunity below, which may be of interest to PhD students finishing their degrees this spring (or able to take a summer break). Candidates from Numerical Relativity would be very welcome. Any questions can be directed to me. Best regards, Eloisa ---------------------------------------------------------------- IBM Research Europe (UK) is offering 3-month internships for PhD students interested in experiencing its research environment in Summer 2024. Applicants should either have just graduated from a doctoral-level course, or be enrolled in one and eligible to take a break to undertake an industrial placement. ? Applications can be submitted at ? https://krb-sjobs.brassring.com/TGnewUI/Search/home/HomeWithPreLoad?PageType=JobDetails&partnerid=26059&siteid=5016&Areq=681129BR#jobDetails=714854_5016 ? A background in Physics is required. Proficiency with scientific AI/ML and hands on experience with HPC systems would be a plus. The deadline for full consideration is 4-Feb-2024, but we will continue to assess candidates until all posts are filled. ---------------------------------------------------------------- From wernecklr at gmail.com Thu Jan 25 09:33:08 2024 From: wernecklr at gmail.com (Leo Rosa Werneck) Date: Thu, 25 Jan 2024 07:33:08 -0800 Subject: [Users] Meeting Minutes 2024-01-25 Message-ID: <11C1E598-2FAE-4998-B4CD-7BB11A557262@gmail.com> Hi all, Please find the minutes for today?s meeting below. Cheers, Leo Chair: Zach Minutes: Leo Present: Zach, Leo, Peter, Steve, Roland, Wenhao, Xinyue, Yosef, Bing-Ran HE Next ET Release: - Managers: Roland & Steve - Steve created a release schedule https://docs.einsteintoolkit.org/et-docs/Release_Details#Schedule - Tomorrow is the initial deadline for proposing functionality to include, but likely will have to be pushed. - BNS simulations still do not work; results are completely different, even in the very beginning. - Roland: is this the first release where the resolution of the simulation was made "sane"? Steve: I didn't change the resolution, simply ran the example following the instructions on the website. - Zach: What release have we been using on our latest runs? Leo: May 2023. Steve: Have you ran the gallery example? Leo: No. Zach: It wouldn't hurt to do it. Leo will launch gallery example for the past two releases. - Elliptica: No one heard from Alireza since the May 2023 release. Release managers may revive the ticket to check if there are any updates. Unanswered Questions on the Mailing List: - None Open Tickets: - POWER: Zach will create a ticket to discuss stylistic issues, as well as errors in the documentation. Additional Topics: - Summer Schools: Steve will host the US one this year. There were proposed dates, but these were rejected. ------ Leonardo R. Werneck, Ph.D. Postdoctoral researcher Office EP 314 | Department of Physics | University of Idaho 875 Perimeter Dr. MS 0903 Moscow, ID 83844-0903, USA leonardo at uidaho.edu https://leowerneck.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From robyn.munoz at yahoo.fr Fri Jan 26 11:49:59 2024 From: robyn.munoz at yahoo.fr (Robyn Munoz) Date: Fri, 26 Jan 2024 17:49:59 +0000 (UTC) Subject: [Users] Compiling ET_2023_11 on Sciama References: <280145465.2239788.1706291399012.ref@mail.yahoo.com> Message-ID: <280145465.2239788.1706291399012@mail.yahoo.com> Hi everyone, I've been unsuccessfully trying to run the latest version of Einstein Toolkit on the Sciama HPC cluster where I have been using the 2020_05 version so far.?Could someone please help?? I have tried three different approaches and put the terminal output and config.log files of each in the folder here (too heavy for email)Compiling_ET_2023_11_on_Sciama - Google Drive as well as the Sciama config files I used in the B approach. A) Using the config files already included in Einstein Toolkit, using intel_comp/2019.2 it gives the error Cactus requires a C++11 compiler -- check your C++ compiler and C++ compiler flags If using g++ at least version 6 is required, if using icpc use -gxx-name to use libstc++ from g++ at least version 6 I tried using intel_comp/2020.1?(the latest available on Sciama) and got the same error (and some module warnings). I found the path to g++ and so tried to add -gxx-name =?/opt/apps/compilers/gnu_comp/cfg/9.1.0/intel64/bin/g++ to?CXXFLAGS in sciama.cfg but this didn't change anything.? B) Using gnu_comp/13.2.0 instead, I changed modules and flags where you can see in the Google Drive folder the .ini and .cfg files I use.?It compiles all the way to the part "Creating cactus_sim" where it lists all the thorns then?I get lots?of errors of the type? patch_system.cc:(.text+0xbe): undefined reference to `H5open' /usr/bin/ld: Dwarf Error: found dwarf version '1', this reader only handles version 2, 3 and 4 information. I have this message for lots of files .cc, .c, .f90 undefined reference to lots of different H5 functions (and also?dsytrf_?dgetrf_?dgesv_??dsysv_??dposv_??dgbsv_)?complaining about dwarf version 'any number'. The only other somewhat similar example I found of this online is here?https://github.com/tinygo-org/tinygo/issues/1415?but it's not that helpful. I'm guessing it's unhappy with hdf5, unfortunately, the latest version on Sciama is 1.10.5. Do I just need a later version of hdf5 or is this something else? C)?I tried with the EinsteinToolkit hdf5 (that I see is version?1.12.0)? with?HDF5_DIR = BUILD and commented out HDF5_LIB_DIRS and HDF5_INC_DIRS, as it compiles it doesn't get as far. In the output, I'm under the impression it manages to build it properly, but later it seems to not be unable to find it, but it should just be within Einstein Toolkit right? Thank you for your help,Robyn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Mon Jan 29 15:18:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 29 Jan 2024 15:18:01 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers From rhaas at illinois.edu Wed Jan 31 17:15:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 31 Jan 2024 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers From robyn.munoz at yahoo.fr Thu Jan 18 11:29:54 2024 From: robyn.munoz at yahoo.fr (Robyn Munoz) Date: Thu, 18 Jan 2024 17:29:54 +0000 (UTC) Subject: [Users] Compiling ET_2023_11 on Sciama and laptop References: <924449056.5473131.1705598995364.ref@mail.yahoo.com> Message-ID: <924449056.5473131.1705598995364@mail.yahoo.com> Hello everyone, 1) I have been using the 2020_05 version of Einstein Toolkit for a while now and wanted to use mesh refinement with periodic boundaries but can't get it to work. I tried to run the test parameter file repos/carpet/PeriodicCarpet/test/ml-gw1d-small-amr.par and am getting the error? while executing schedule bin BoundaryConditions, routine PeriodicCarpet::PeriodicCarpet_ApplyBC ? in thorn PeriodicCarpet, file /users/munozr/code/2020_05/Cactus/arrangements/Carpet/PeriodicCarpet/src/periodic.cc:181: ? -> Cannot handle more than one local component In the PeriodicCarpet thorn documentation I see " it provides correct behaviour for the case where a refinement level overlaps the periodic boundaries, and may therefore be made up of more than one component on the same process " so I think somewhere there, there is an issue so I figured I should try with the latest version of EinsteinToolkit. 2) I got a new laptop Mac Sonoma 14.2.1, so I've been installing the latest Xcode etc. I downloaded EinsteinToolkit 2023_11 and tried to compile it, I ran into issues with SGRID (and DNSdata) and ADIOS2 I see there are tickets about them and I don't need them so I commented them out. Now when I compile the code I get the terminal output and config.log attached. I can't decipher exactly what the issue is from those. Please let me know what I can do to fix this. 3) I also tried to compile ET_2023_11 on the Sciama HPC as well (where the 2020_05 version works well), because of the security of Sciama, I used GetComponents on my laptop, compressed Cactus and scp to Sciama. Then the sciama.ini .cfg .run and .sub files are already included in EinsteinToolkit where I use system/intel64 and intel_comp/2019.2 this gives me the error Cactus requires a C++11 compiler -- check your C++ compiler and C++ compiler flags If using g++ at least version 6 is required, if using icpc use -gxx-name to use libstc++ from g++ at least version 6 Error reconfiguring sim-config I tried using intel_comp/2020.1 (latest available on sciama) and got the same error (and some module warnings). I found the path to g++ and so tried to add -gxx-name =?/opt/apps/compilers/gnu_comp/cfg/9.1.0/intel64/bin/g++ to CXXFLAGS in sciama.cfg but this didn't change anything.?Please let me know what I can do to fix this. Thank you for your help,Robyn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 43160 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: terminal_output.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Sciama_config.log Type: application/octet-stream Size: 173462 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Sciama_terminal_output.txt URL: From sdtootle at uidaho.edu Thu Jan 18 22:05:05 2024 From: sdtootle at uidaho.edu (Samuel Tootle) Date: Thu, 18 Jan 2024 20:05:05 -0800 Subject: [Users] meeting minutes for 2024-01-18 In-Reply-To: References: Message-ID: Steve et al: I'm very open to including a gallery example in the up-coming release.? If you have some ideas, preferences, or constraints (i.e. has to be computed in a certain amount of time on a certain number of cores); let me know.? I have been testing the new development importers for FUKA ID with IGM and GRHayl, so it's possible we could combine some of these ideas for gallery examples. Cheers, Samuel -------------------------------- Postdoctoral Researcher Department of Physics University of Idaho https://samueltootle.github.io On 1/18/24 7:47 AM, Steven Brandt wrote: > Present: Bing-Ran HE, Steve, Roland, Lihaichang, Sam Cupp, shenfei, > Zach, Leo > Chair: Roland > Minutes: Steve > > Need to have a release schedule > > List of updates for the next release: > ??? Reprimand - is there a use case? > ??? Gallery examples for ID readers FUKA, Sgrid, Canuda > ??? TOV solver based on Grhayl, tabulated EOS builtin > ??? New Grhayl-based MHD thorns - Gallery example? > ??? New tabulated eqn state > ??? Baikal updates > > Bing asked about initial data > ??? he did not feel LORENE was friendly > ??? Roland pointed him to FUKA and Sgrid > http://einsteintoolkit.org/thornguide/ExternalLibraries/SGRID/documentation.html > > http://einsteintoolkit.org/thornguide/Fuka/KadathImporter/documentation.html > > > Roland will try and replicate failure of BNS > > Trying again to get the check from SPEC > > No unanswered questions on the email list > > Open tickets: > ??????? 2772 Kadath - linking issue on systems with mkl > ??? and 2755 POWER - Doesn't compute angular momentum correctly (wrong > formula) > > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users From chloer3 at illinois.edu Mon Jan 29 16:53:52 2024 From: chloer3 at illinois.edu (Richards, Chloe Beth) Date: Mon, 29 Jan 2024 22:53:52 +0000 Subject: [Users] Compiling ET_2023_11 on Frontera Message-ID: Hi everyone, I tried to compile the most recent release of the toolkit, ET_2023_11, on Frontera using simfactory and had some issues compiling certain thorns. In case there are others that are having similar issues, I was able to successfully compile once I commented out the following lines/thorns: * ExternalLibraries/Silo * GRHayL Library and GRHayL-dependent thorns * CarpetX thorns If users have successfully compiled with the thorns I commented out, please let me know. Thanks! Best, Chloe Richards -------------- next part -------------- An HTML attachment was scrubbed... URL: