Users March 2016

users@lists.einsteintoolkit.org

10 participants
13 discussions

Re: [Users] [ET Trac] [Einstein Toolkit] #1326: running loopcontrol on strange number of threads fails
by Erik Schnetter 11 Apr '19

11 Apr '19

Do you have a backtrace? -erik On Sunday, March 22, 2015, Einstein Toolkit < trac-noreply(a)einsteintoolkit.org> wrote: > #1326: running loopcontrol on strange number of threads fails > ------------------------------------+--------------------------------------- > Reporter: rhaas | Owner: > Type: defect | Status: new > Priority: minor | Milestone: > Component: EinsteinToolkit thorn | Version: > Resolution: | Keywords: LoopControl > ------------------------------------+--------------------------------------- > > Comment (by rhaas): > > This still happens even with current (Sun Mar 22 18:46:21 CET 2015) trunk, > though failure looks a bit different now: > {{{ > actus_sim: > /data/rhaas/postdoc/gr/ET_trunk/configs/sim/build/LoopControl/loopcontrol.cc:312: > T {anonymous}::divexact(T, T) [with T = int]: Assertion `i % j == 0' > failed > }}} > > -- > Ticket URL: <https://trac.einsteintoolkit.org/ticket/1326#comment:1> > Einstein Toolkit <http://einsteintoolkit.org> > The Einstein Toolkit > _______________________________________________ > Trac mailing list > Trac(a)einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/trac > -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

3 2

No Einstein Toolkit Meeting
by Frank Loeffler 12 Jun '16

12 Jun '16

Hi, There will *not* be an Einstein Toolkit meeting today (Mon Feb 08th). The next meeting will be on Mon Feb 15th, 2016, at the new time (half an hour earlier than 'usually': 9:30am US central time). Frank Loeffler

1 1

meeting minutes for 2015-08-31
by Roland Haas 11 Apr '16

11 Apr '16

Present: Frank, Roland, Steve, Peter, Matt, Josh, Erik, Zach, Jonah, Elo There will be no ET call next week due to labour day/Thanksgiving weekend in North America. IllnoisGRMHD: * report is with Zach, was send via private email * separate repo is fine, Zach will create a repository * volunteer needed for the compatibility thorn * Zach will move compatibility thorns into same repo as IllinoisGRMHD GetComponents on OSX: * no OSX user has written * Roland will propose a patch simfactory on BeeGFS: * Erik will look into Bruno's proposed patch writing timeseries data into hdf5: * Frank would like to use this for things like the Hamiltonian norm * HDF5 supports extensible datasets, an example on how to use this is the HDF5 output of Multipole SPH in Cactus: * Matt has a more or less working version of SPH on grid background * came out of work at a national lab on generic grid methods * currently linked in a shared objects for mesh handling and nearest neighbour finding * currently writing his thesis, so code is not changing much right now * load balancing through bisection initially then times the RHS and neighbour looked up push particles around * no octree, instead a hierarchical hash * particle to grid data currently uses SPH approximation for Tmunu at gridpoints of Cactus grid * will arrange for time for presentation through mailing list 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://keys.gnupg.net.

10 51

Einstein Toolkit Meeting Reminder
by Frank Loeffler 27 Mar '16

27 Mar '16

Hi Please consider joining the weekly Einstein Toolkit phone call at 9:30 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: *** Please note that a lot of countries, including most of the US and Europe, are now using daylight savings (summer) time. For those, the meeting time is now 'back to usual' after last weeks difference. (This time for real.) *** http://einsteintoolkit.org/community/support/ We use a Google hangout, with the URL: https://hangouts.google.com/call/5xt7voshalqmdcztr4zhfeox2ia Frank Löffler

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 21 Mar '16

21 Mar '16

Hi Please consider joining the weekly Einstein Toolkit phone call at 9:30 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: *** Please note that a lot of countries, including most of the US and Europe, are now using daylight savings (summer) time. For those, the meeting time is now 'back to usual' after last weeks difference. *** http://einsteintoolkit.org/community/support/ We use a Google hangout, with the URL: https://hangouts.google.com/call/5xt7voshalqmdcztr4zhfeox2ia Frank Löffler

3 2

Einstein Toolkit Meeting Reminder
by Frank Loeffler 13 Mar '16

13 Mar '16

Hi Please consider joining the weekly Einstein Toolkit phone call at 9:30 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: *** Please note that most parts of the US changed to summer time this weekend, which means if you didn't change (yet), the meeting will be one hour *EARLIER* than last week. *** http://einsteintoolkit.org/community/support/ We use a Google hangout, with the URL: https://hangouts.google.com/call/5xt7voshalqmdcztr4zhfeox2ia Frank Löffler

1 0

Re: [Users] Problem with accretion of magnetised gas and mesh refinement
by Petra Suková 11 Mar '16

11 Mar '16

Hello, thanks for you reply. I was not aware about the Llama code. I will have a look at this and also at the overlap zones, if it will help. Best regards, Petra -----Původní zpráva----- From: Philipp Moesta Sent: Wednesday, March 9, 2016 6:46 PM To: users(a)einsteintoolkit.org Cc: psukova(a)cft.edu.pl Subject: Re: [Users] Problem with accretion of magnetised gas and mesh refinement Hi Petra, to add to this. The problem you are describing sounds very familiar to me. I had faced similar issues in simulating magnetized core-collapse with AMR. One thing that helped me a lot was utilizing additional buffer zones (called 'overlap' zones). Using these seem to effectively decouple the divB violations from the bulk of the grid when using constrained transport. The relevant parameter is Carpet::use_overlap_zones = "yes" All that said, you may want to follow Erik's suggestion and use multi-block for simulating gas accretion onto a black hole. Best, Philipp On 3/9/16 7:23 AM, Erik Schnetter wrote: > Petra > > Without going into the details of the issues you are encountering: > > Accretion onto a black hole has a near-spherical or axisymmetric > symmetry. In my experience, this is better modelled using a > multi-block structure than mesh refinement. Are you aware of > <http://llamacode.bitbucket.org>? > > -erik > > > On Wed, Mar 9, 2016 at 10:10 AM, Petra Suková <psukova(a)cft.edu.pl> wrote: >> Hello everyone, >> >> I am a postdoc at CFT PAN Warsaw and a relatively new user of ET. I am >> trying to use ET for simulating accretion of low angular momentum >> magnetised >> gas onto Kerr black hole. >> >> I use GRHydro and GRHydro_Init thorns on stationary Kerr spacetime. Using >> mesh refinement with nonzero magnetic field always leads to crash of the >> computation, after few hundreds or thousands of iterations. It looks like >> the cause of the crash is violation of divB=0 constrain in the buffer >> zones >> on the edge of refined level, which grows and later starts to propagate >> into >> the grid. >> >> More details: >> I have adapted GRHydro_BondiM.c and run some tests with low angular >> momentum >> accretion, B=0, spin=0 and several refinement levels, which after some >> modifications worked quite well. Now I am trying to include magnetic >> field. >> I have set initially vertical magnetic field. After first iteration, divB >> in >> the buffer zones increases to values around 10e-7 and it is growing >> during >> the evolution. After some time (depending on the Bfield strength, grid >> size >> etc, typically tens or hundreds of M), the values of divB in the buffer >> zones exceed 0.1 and start to spread inside the grid zones and spoil the >> simulation. >> I thought, that maybe some of my changes caused this, so I tried to run >> an >> example par file MBondi_B5.70_Mdot12.57_Npts100_Sch.par with clean ET >> release 12, but that crashed immediately in the first iteration. So I >> tried >> to lower bondi_bmag from 5.7 to 0.1 and this worked and was stationary, >> but >> it runs only on unigrid without refinement. When I added the mesh >> refinement >> and fixed GRHydro_BondiM_Boundary to not act on the refinement boundary, >> the >> same problem with buffer zones appears. I am attaching the par file of >> this >> computation together with few snapshots of divB, rho and Bvec. >> My guess is that during the prolongation and restriction of magnetic >> field >> vector the DivB=0 condition is violated and this error is continuously >> increasing when the Bfield and matter is accreted through the refinement >> boundary. >> Has anyone faced similar problem? Or does anyone have some working >> parfile >> with similar computation with magnetised gas and at least two refinement >> levels, which he can send me? I could test that and hopefully discover my >> problem. >> >> Thanks a lot, >> Petra >> >> --- >> Tato zpráva byla zkontrolována na viry programem Avast Antivirus. >> https://www.avast.com/antivirus >> >> _______________________________________________ >> Users mailing list >> Users(a)einsteintoolkit.org >> http://lists.einsteintoolkit.org/mailman/listinfo/users >> > > > -- Philipp --- Tato zpráva byla zkontrolována na viry programem Avast Antivirus. https://www.avast.com/antivirus

1 0

Fwd: commit/SimFactory2: eschnett: Revert "simremote: handle symbolic links in basedir gracefully"
by Erik Schnetter 10 Mar '16

10 Mar '16

I reverted this commit because it broke Simfactory. It leads to errors such as $ ./simfactory/bin/sim --remote nvidia execute date Traceback (most recent call last): File "./simfactory/bin/../lib/sim.py", line 148, in <module> main() File "./simfactory/bin/../lib/sim.py", line 141, in main RemoteExecute(remoteMachine) File "./simfactory/bin/../lib/sim.py", line 113, in RemoteExecute RemoteEnvironment.ExecuteSameCommand(parrotArguments=True, stripArguments=['remote', 'remotecactuspath', 'machine']) File "/Users/eschnett/Cvanilla/repos/simfactory2/lib/simremote.py", line 71, in ExecuteSameCommand remoteExe = self.GetRemoteExePath(localSourceBaseDir, sourceBaseDir) File "/Users/eschnett/Cvanilla/repos/simfactory2/lib/simremote.py", line 52, in GetRemoteExePath self.RemotePath = simlib.ReplaceLeadingPath(simenv.CACTUS_PATH, simlib.GetLocalSourceBaseDir(), remotes) AttributeError: 'module' object has no attribute 'ReplaceLeadingPath' If you look at the code, it indeed seems there is no routine with the name "ReplaceLeadingPath". I assume that's a small error that is easily corrected; in the mean time, I reverted this to ensure Simfactory remains usable. -erik ---------- Forwarded message ---------- From: Bitbucket <commits-noreply(a)bitbucket.org> Date: Thu, Mar 10, 2016 at 9:19 PM Subject: commit/SimFactory2: eschnett: Revert "simremote: handle symbolic links in basedir gracefully" To: commits(a)cactuscode.org 1 new commit in SimFactory2: https://bitbucket.org/simfactory/simfactory2/commits/2ed3398ecfe9/ Changeset: 2ed3398ecfe9 Branch: master User: eschnett Date: 2016-03-11 02:19:31+00:00 Summary: Revert "simremote: handle symbolic links in basedir gracefully" This reverts commit f4407d48f500e6821218af8b6283e91826c52f7f. Affected #: 1 file Repository URL: https://bitbucket.org/simfactory/simfactory2/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. _______________________________________________ Commits mailing list Commits(a)cactuscode.org http://cactuscode.org/mailman/listinfo/commits -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

2 1

Make refluxing available to all
by David Radice 09 Mar '16

09 Mar '16

Hi all, sorry for the spam, but I would like to give a little bit of advertisement to this ticket: https://trac.einsteintoolkit.org/ticket/1862 I propose a patch for the Refluxing thorn that will decouple it from GRHydro. With the proposed changes, any evolution thorn will be able to register variables for refluxing in a very simple way (see the GRHydro_Refluxing thorn in the ticket for an example). For instance, it should be possible to add conservative AMR to the IllinoisGRMHD code. My code "WhiskyTHC" is already making use of this capability. I would be happy for any feedback on these patches and I hope they can make their way into the Einstein Toolkit. Thank you and best, David

1 0

Problem with accretion of magnetised gas and mesh refinement
by Petra Suková 09 Mar '16

09 Mar '16

Hello everyone, I am a postdoc at CFT PAN Warsaw and a relatively new user of ET. I am trying to use ET for simulating accretion of low angular momentum magnetised gas onto Kerr black hole. I use GRHydro and GRHydro_Init thorns on stationary Kerr spacetime. Using mesh refinement with nonzero magnetic field always leads to crash of the computation, after few hundreds or thousands of iterations. It looks like the cause of the crash is violation of divB=0 constrain in the buffer zones on the edge of refined level, which grows and later starts to propagate into the grid. More details: I have adapted GRHydro_BondiM.c and run some tests with low angular momentum accretion, B=0, spin=0 and several refinement levels, which after some modifications worked quite well. Now I am trying to include magnetic field. I have set initially vertical magnetic field. After first iteration, divB in the buffer zones increases to values around 10e-7 and it is growing during the evolution. After some time (depending on the Bfield strength, grid size etc, typically tens or hundreds of M), the values of divB in the buffer zones exceed 0.1 and start to spread inside the grid zones and spoil the simulation. I thought, that maybe some of my changes caused this, so I tried to run an example par file MBondi_B5.70_Mdot12.57_Npts100_Sch.par with clean ET release 12, but that crashed immediately in the first iteration. So I tried to lower bondi_bmag from 5.7 to 0.1 and this worked and was stationary, but it runs only on unigrid without refinement. When I added the mesh refinement and fixed GRHydro_BondiM_Boundary to not act on the refinement boundary, the same problem with buffer zones appears. I am attaching the par file of this computation together with few snapshots of divB, rho and Bvec. My guess is that during the prolongation and restriction of magnetic field vector the DivB=0 condition is violated and this error is continuously increasing when the Bfield and matter is accreted through the refinement boundary. Has anyone faced similar problem? Or does anyone have some working parfile with similar computation with magnetised gas and at least two refinement levels, which he can send me? I could test that and hopefully discover my problem. Thanks a lot, Petra --- Tato zpráva byla zkontrolována na viry programem Avast Antivirus. https://www.avast.com/antivirus

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users March 2016