Hello,
The parameter N defines the numerical resolution, i.e. the grid spacing,
used in the simulation.
The setup of a Llama multipatch system is somewhat complicated, so in
GW150914.rpar, N is used to calculate all the necessary quantities
for setting the coordinate system up. A larger value
Hi Thejas,
In the Einstein Toolkit, we use, as is common in numerical relativity,
units where the speed of light, c, and the gravitational constant, G, are
chosen to be c=G=1. In addition, we measure mass in units of the solar
mass, M_sun. 1 solar mass can be converted into a length by
Dear Spendan,
You say your simulations performed 2840 timesteps in half an hour on 32
procs, which is 5680 timesteps per hour. Running for a full day you get
132105 timesteps, i.e. 5504 timesteps per hour. So you're right there is a
small difference in speed. However, remember that the grid
Hi Jessica,
I don't know if this is related to your problem, but I recently saw a
similar problem on a new machine here at LSU that also uses SLURM. Some
jobs would run but other would crash with a segmentation fault. It turned
out that whether the job would crash or not depended on the memory
Hi Nick,
If I understand your notation g_yy(0,1,0) correctly to mean g_yy along the
y axis and g_yy(1,0,0) to g_yy along the x-axis, the statement you make is
not correct. What you would expect in a spherically symmetric spacetime is
that g_xx(1,0,0)=g_yy(0,1,0)=g_zz(0,0,1), i.e. gxx along x
iss = 0.1, It worked, no
more large violation near refinement boundaries.
However, not very sure about how these two "epsdis" work differently.
BR
KZ
________
From: Peter Diener
Sent: Thursday, July 8, 2021 10:47
Hi Kenneth,
It is expected that the mesh refinement boundaries will reflect
Hamiltonian constraint violations. From what you have provided us, it is
not clear whether the level of constraint violations that you see is a
cause of concern. You specifically mention CCZ4, but have you tried with
Hi Adam,
If it indeed turns out that your problem can be cast as a 4th order
elliptical PDE, I don't see any reason why this could not be simulated.
In fact in the thorn NoExcision, we actually use up to a 6th order
ellitpical PDE to fill in the interior of a black hole with constraint
Hi Karima,
Yes, that parameter file requires at least 2 mpi processes to run.
You seem to have submitted using simfactory and ended up running on 1
mpi process awith 2 openmp threads. If you instead do something like
simfactory/bin/sim run bbhHr --cores=2 --num-threads=1
if you're on a
Hi Nick,
Your approach of modifiying TOVSolver::TOV_Rho_Central[0] in your
parameter file just results in an different equilibrium
solution.
However, the TOV-solver actually have built in parameters for doing
exactly what you want.
If you set
TOVSolve::Perturb[0] = "yes"
you can add a
Hi Miguel,
I have commented on the ticket you created about this. Please take a
look at that comment and let me know what you think.
Cheers,
Peter
On Thursday 2020-04-09 13:08, Miguel Zilhão wrote:
Date: Thu, 9 Apr 2020 13:08:47
From: Miguel Zilhão
To: Einstein Toolkit Users
Subject:
Hi Erik,
McLachlan is a thorn generated from a tool named Kranc from
high level tensorial expressions in Mathematica. So if you have
access to Mathematica you can add additional lapse conditions in the
mathematica source file located in:
arrangements/McLachlan/m/McLachlan_BSSN.m
and then
When we asked for reviewers on the ET call, I mentioned that the code is
still private on the bit buckets and that people interested in looking
at the code should contact me so I could grant permissions. The reason
being that I'm still finishing up the code test paper. If you send me
your
Present: Chris, Maria, Yosef, Peter.
Self-force code in ET:
* Steve has started reviewing the code.
Buffer zones:
* Yosef asked what the status is on implementing Bishop Mongwane's mesh
refinemement scheme to get buffer zones. Nobody on the call remembered
so we pass on the question to the
Hi Erik,
I do believe that epsDiss=0.1 should be fine for 8th order dissipation.
The dissipation operators should be multiplied by suitable factors so
that the range of good dissipation strength values should be the same
regardless of dissipation order.
Regarding you second question about
Hi Severin,
The globalDiff_gv routine you refer to under the hood calculates the
derivatives with respect to whatever coordinates the current patch
system is using within the current patch and then uses the Jacobian
(passed in) to convert to global (hence the name) cartesian derivatives.
, Peter Diener wrote:
>Date: Fri, 16 Nov 2018 15:20:56
>From: Peter Diener
>To: Roland Haas
>Cc: Erik Schnetter ,
>Andrea Endrizzi ,
>Einstein Toolkit Users
>Subject: Re: [Users] Summatiobyparts compilation failure on ARA cluster (latest
> ET release)
>
hi Roland,
FPPFLAGS=-traditional
was included in the optionlist that Andrea attached to the e-mail.
Cheers,
Peter
On Friday 2018-11-16 15:17, Roland Haas wrote:
>Date: Fri, 16 Nov 2018 15:17:08
>From: Roland Haas
>To: Peter Diener
>Cc: Erik Schnetter ,
>
Hi Andrea,
The error message points to line 11 in the source file, which is the
line that contains
DECLARE_CCTK_FUNCTIONS
This is expanded by a C-preprocessor before being handed of to the
compiler.
The preprocessed file can be found in the directory:
Hi All,
Sorry about the late e-mail but this is just a reminder that next week's
Users Call will take place at the usual time (Monday at 10:00am US
Eastern time) and the usual place (https://bluejeans.com/194244555).
If you have any items for the agenda please add them to the wiki
Hi All,
This is just a reminder that next week's Users Call will take place at
the usual time (at 10:00am US Eastern time on Monday) and the usual
place (https://bluejeans.com/194244555).
If you have any items for the agenda please add them to the wiki
Hi All,
This is just a reminder that next week's Users Call will take place at
the usual time (at 10:00am US Eastern time) and the usual place
(https://bluejeans.com/194244555).
If you have any items for the agenda please add them to the wiki
Hi All,
This is just a reminder that next week's Users Call will take place at
the usual time (at 10:00am US Eastern time) and the usual place
(https://bluejeans.com/194244555).
If you have any items for the agenda please add them to the wiki
Sending this on behalf of Steve
Hi
Please consider joining the weekly Einstein Toolkit phone call at
9:30 am US central time on Mondays.
https://docs.einsteintoolkit.org/et-docs/Main_Page
[docs.einsteintoolkit.org]
Sorry for the short notice.
--Steve
Hi Miguel,
Here's a bit more information. There is no support in McLachlan for
using LegoExcision. LegoExcision was used with an old implementation of
BSSN. As Jonah said, when using Llama, it's possible to do excision
by using a six-patch coordinate setup. In principle it is also possible
to
Hi Gwyneth,
On Wednesday 2016-12-28 15:00, Gwyneth Allwright wrote:
Date: Wed, 28 Dec 2016 15:00:10
From: Gwyneth Allwright <allgwy...@myuct.ac.za>
To: Peter Diener <die...@cct.lsu.edu>
Cc: users@einsteintoolkit.org
Subject: Re: [Users] McLachlan Shift Condition
Hi Peter,
Thank
Hi Gwyneth,
The parameters to control the gamma driver shift condition is something
that we would like to make more transparent. I have to go and look at
the Kranc code, in order to figure out how things work.
When ShiftBCoeff = 1 and ShiftAdvectionCoeff = 1 (both are the default
values) we
Hi Ian,
I haven't tried to use Lapack routines from Cactus, but I have other
Fortran codes where I do.
I have a code, where I just link the library (or add -mkl to the link
line if I use the intel compilers) without even including 'use lapack'
in the source file.
How does you cactus link
Hi,
This issue is discussed for example in
http://arxiv.org/abs/1003.4681
where a non-constant damping in the gamma driver shift is presented to
handle unequal mass binaries. As far as I remember there may also be
later papers with further improvements to the method.
Cheers,
Peter
On
Hi Erik,
I just tried a completely new checkout and compiled with the Intel 14.0.2
compilers without any problems. It is certainly possible that the
optionlist only works for with the right environment setting. In my .soft
file I have:
+default
+Intel-14.0.2
+openmpi-1.6.5-Intel-13.0.0
Does
I didn't get this in before the ticket was closed but thought the
following might be useful.
I believe most compilers (if not all) use unit 0 as stderr, but this is
not guaranteed by the standard. However, a fortran 2003 compliant compiler
provides an intrinsic module 'iso_fortran_env' that
Hi Ian,
As far as I know this wors fine. I have used it in EHFinder to evolve the
generators of the horizon, where the coordinates are stored as 1-d grid
arrays (like xg and its rhs dxg). However, I haven't run that code in a
while, so I can't guarantee that it still works. I'm also using it
Hi Roland,
I had a need for a similar thing some time ago. I had a 2D array that I
only wanted to split in one direction. The workaround that I used was to
declare this as a vector of 1D arrays. However, a more general
implementation, where you can specify it in the interface.ccl would be
33 matches
Mail list logo
