Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Example parameter files / test cases and EOS_Omni changes
by Erik Schnetter 21 Jan '11

21 Jan '11

Dear Einstein Toolkit users Many of the Einstein Toolkit hydrodynamics example parameter files and test cases do not work any more because thorn EOS_Omni is not activated and the corresponding parameters are not set. This is something where everybody can help, and it is important in the long term to have working test cases. I suggest that we add to the Wiki a description of how to update a parameter file (which thorns to add/remove, how to modify parameters). We can then take the existing parameter files and update them. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

Slight changes to GetComponents options
by Eric Seidel 20 Jan '11

20 Jan '11

Hi all, I would like to mention two changes to the options for GetComponents. 1. I recently revised the system for running commands, and during that process I decided that I really only need two levels of verbosity, verbose and regular. Therefore GetComponents will no longer differentiate between '-v' and '-v -v'. Adding the second -v will not trigger an error though, it just won't add to the verbosity any more. 2. The parallel checkout mode (-p or --parallel) is substantially more stable now. It will checkout/update up to 4 components at a time. I would like to eventually have a parallel checkout be the default, likely adding an option to control how many threads to use, but first I would like to get feedback from you. So if you are using the git version of GetComponents, please test the parallel checkout/update option, and let me know if you see any issues. Thanks, Eric

1 0

Meeting Reminder
by Frank Loeffler 17 Jan '11

17 Jan '11

2 1

Meeting minutes
by Roland Haas 11 Jan '11

11 Jan '11

Meeting minutes: Present were: Frank, Roland, Peter, Eric, Scott, Erik, Bruno, Christian status updates of work done over Christmas/New Year GRHydro (MHD): * use EOS_Omni instead of the old interface * fixed some bugs in the divergence cleaner * race conditions in MHD branch when using OpenMP (static variables in Con2PrimM) GRHydro (hot EOS): * some debugging * added OpenMP support * addressed some issues with Carpet/Hg * fixed recent PPM bug (affects all versions, but was introduced recently into trunk) * the GetComponents repository has moved to GitHub for good now, the copy in subversion will no longer be used * we will try and move the bug tracker to a generic URL. See discussion on Cactus developers mailing list (http://cactuscode.org/pipermail/developers/2011-January/006147.html) * development of the initial data solver will be made somewhat more public but still restricted to the core ET people (details to be worked out, if you need access please write to Frank Loeffler). We need to finish the initial data solver and start working on the paper. We will have two papers using this, one paper only on initial data which will have a short author list of those who contributed and a second publication as part of the general ET code paper. * we want to begin assigning section for people to write in the general ET code paper https://svn.einsteintoolkit.org/documents/Paper_EinsteinToolkit_2010 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.

1 0

Re: [Users] [Developers] undefined reference to `GenericFD_GetBoundaryWidth'
by Ian Hinder 11 Jan '11

11 Jan '11

On 11 Jan 2011, at 14:05, Barry Wardell wrote: > On 11/01/2011 11:39, Alexander Beck-Ratzka wrote: >> Hi Folks, >> >> I have an undefined reference to `GenericFD_GetBoundaryWidth'. Where can >> I get it? >> > Hi Alexander, > > GenericFD is a thorn provided as part of Kranc (http://kranccode.org/). > It's in Auxiliary/Cactus/KrancNumericalTools in the Kranc git repository > (https://github.com/ianhinder/Kranc/tree/master/Auxiliary/Cactus/KrancNumeri…). Hi Alexander, According to the email you sent me, you have checked out Kranc using an Einstein Toolkit thornlist from the branch ET_2010_06. In the version of Kranc for that branch, the GenericFD_GetBoundaryWidth function did not yet exist. Now, for some reason, you have a version of WeylScal4 which has been generated with a newer version of Kranc and uses this function. Did you check out WeylScal4 from the same thornlist? Can you post the section of the thornlist which refers to WeylScal4? -- Ian Hinder ian.hinder(a)aei.mpg.de

1 0

phone line problems
by Frank Loeffler 10 Jan '11

10 Jan '11

Hi, Those who called in this morning probably heard a lot of interesting, but disturbing ... things. Let's try another conference line: Each participant of the teleconference will call 578-4942 (225-578-4942 from off-campus or 866-573-0359 toll fre e). Participants will press 338310# for Conference Line two. Frank

1 2

Meeting Reminder
by Frank Loeffler 09 Jan '11

09 Jan '11

Hi, This is a reminder about our usual Monday Einstein Toolkit phone call. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/info/support/ The call will take place tomorrow, January 10th, at 10am US central time. I have seen a lot of changes to the toolkit over the holidays and I am sure I am not the only one who would like a summary. I would also like to (shortly) discuss / get opinions about moving the ET bug tracker (in the mid-term) to another, more general domain, e.g. opensciencetoolkits.org. Only the domain would change, I would like to keep the current system the same, but then extend and open it also to other non-ET releated projects which e.g. use Cactus. Frank Loeffler

1 0

GRHydro prim2con
by Ernazar Abdikamalov 07 Jan '11

07 Jan '11

GRHydro doesn't compile on numrel08. It is complaining about a type mismatch: In routine primitive2conservative, variable xtemp is defined as CCTK_REAL :: xtemp and is used as an output variable in routine prim2con_hot. However, inside prim2con_hot, the corresponding variable is defined as real*8 temp0(1). I don't know exactly why this doesn't compile. However, if, for example, one defines xtemp in routine primitive2conservative as CCTK_REAL :: xtemp(1), then it compiles. I've attached the corresponding patch to this message. Is it okay to apply it? Thanks, Ernazar

2 1

Re: [Users] reduction in carpet + mismatched declaration in ML_ADMQuantities
by Hee Il Kim 07 Jan '11

07 Jan '11

Christian, thanks so much ! Your code seems to contain everything I wanted to calculate. There's one minor mismatched declaration in ML_ADMQuantities which should be fixed anyhow. #### [khi@zenith src]$ diff ML_ADMQuantities.c.ori ML_ADMQuantities.c 56c56 < const char *groups[] = {"grid::coordinates","Grid::coordinates","McLachlan::ML_curv","McLachlan::ML_Gamma","McLachlan::ML_lapse","McLachlan::ML_log_confac","McLachlan::ML_metric","McLachlan::ML_shift","McLachlan::ML_trace_curv","ML_ADMQuantities::ML_Jadm","ML_ADMQuantities::ML_Madm"}; --- > const char *groups[] = {"grid::coordinates","Grid::coordinates","ML_BSSN::ML_curv","ML_BSSN::ML_Gamma","ML_BSSN::ML_lapse","ML_BSSN::ML_log_confac","ML_BSSN::ML_metric","ML_BSSN::ML_shift","ML_BSSN::ML_trace_curv","ML_ADMQuantities::ML_Jadm","ML_ADMQuantities::ML_Madm"}; #### Thanks again, Hee Il 2011/1/5 Christian D. Ott <cott(a)tapir.caltech.edu> > > Dear Hee Il, > > I agree that getting this right is tricky. You must set up your grid > functions that you want to reduce in MoL_PseudoEvolution in local > mode, then do the reduction in CCTK_Analysis in global mode. > > I am attaching a Thorn called ZelmaniAnalysis that I use for the > kinds of things you want. The reduction works with Carpet. > > Best, > > - Christian > > > > On Wed, Jan 05, 2011 at 09:18:21PM +0900, Hee Il Kim wrote: > > Hi, > > > > Belated Happy New Year ! > > > > I am writing a simple code for the calculation of ADM mass and angular > > momentum by using ML_ADMQuantities. As you know, it requires reduction > > procedure for the summation of the integrand, e.g., density * volume > > measure. I've tried various reduction APIs including old deprecated one, > but > > I could only succeed in the integration only over the coarsest grid > level, > > which was not accurate. > > > > If I use the new reduction API in the reference manual of Cactus, > > CCTK_ReduceGridArrays; > > > > CCTK_ReduceGridArrays(const cGH *GH, > > int dest_processor, > > int local_reduce_handle, > > int param_table_handle, > > int N_input_arrays, > > const CCTK_INT input_array_variable_indices[], > > int M_output_values, > > const CCTK_INT output_value_type_codes[], > > void* const output_values[]); > > > > , I encounter the following error > > .... > > WARNING[L3,P0] (Cactus): CCTK_ReduceGridArrays: no grid array reduction > > registered > > WARNING level 0 in thorn ML_Analysis processor 0 host compute-0-5.local > > (line 159 of Evaluate_ADMQuantities.F90): > > -> Failed to integrate J_z > > > > Param_table_handle is not clear to me but it seems not causing the > problem. > > The reduction operators are registered by CactusBase/LocalReduce. > > > > Could you let me know which reduction function I have to use for this > > calculation? I mean the integration over the whole grid levels. Should I > do > > loop over refinenment levels; > > ... > > do loop over reflev > > call CCTK_Reduce > > enddo > > ... > > > > Thanks in advance, > > > > Hee Il > > > _______________________________________________ > > Users mailing list > > Users(a)einsteintoolkit.org > > http://lists.einsteintoolkit.org/mailman/listinfo/users > >

4 5

CarpetIOScalar: avoiding "reductions" for scalar variables
by Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] 05 Jan '11

05 Jan '11

Hi all. This seems trivial, but ... How do I avoid reductions (average, minimum, maximum, etc) for scalar output of a SCALAR variable in CarpetIOScalar? CactusBase/IOBasic recognises the SCALAR type of the variable, and doesn't bother with reduction. Carpet/CarpetIOScalar seems to ignore the type, and does the reductions. At least, it outputs several files with trivial information in them. I can force it to only generate one file by setting outscalar_reductions ="average" (for instance), but then I lose the reductions for all other (non-SCALAR) variables. Thanks, Bernard [working with the Chandrasekhar release of ETK]

2 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users