Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

ReadWriteDiagnostic thorn
by Steven R. Brandt 04 Apr '16

04 Apr '16

!TARGET = $ARR !TYPE = git !URL = https://git.cct.lsu.edu/sbrandt/ReadWriteDiagnostics.git !REPO_PATH=$2 !CHECKOUT = ReadWriteDiagnostics/ReadWriteDiagnostic Cheers, Steve

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 04 Apr '16

04 Apr '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: 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 28 Mar '16

28 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 14 Mar '16

14 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 11 Mar '16

11 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

Einstein Toolkit Meeting Reminder
by Frank Loeffler 06 Mar '16

06 Mar '16

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users