From frank.loeffler at aei.mpg.de Wed Jul 4 02:48:31 2007
From: frank.loeffler at aei.mpg.de (Frank =?utf-8?Q?L=C3=B6ffler?=)
Date: Wed, 4 Jul 2007 09:48:31 +0200
Subject: [Developers] ADMMacros, syntax errors in C version
Message-ID: <20070704074831.GJ12161@peterpan.ap.op.sissa.it>
Hi,
this patch fixes two missing ";" in the C version.
Frank
Index: ADMMacros/src/macro/HAMADM_guts.h
===================================================================
RCS file: /cactusdevcvs/CactusEinstein/ADMMacros/src/macro/HAMADM_guts.h,v
retrieving revision 1.7
diff -u -r1.7 HAMADM_guts.h
--- ADMMacros/src/macro/HAMADM_guts.h 18 Nov 2004 14:18:24 -0000 1.7
+++ ADMMacros/src/macro/HAMADM_guts.h 4 Jul 2007 07:38:35 -0000
@@ -27,9 +27,9 @@
#ifdef CCODE
- HAMADM_HAMADM = TRRICCI_TRRICCI - TRKK_TRKK + TRK_TRK*TRK_TRK
+ HAMADM_HAMADM = TRRICCI_TRRICCI - TRKK_TRKK + TRK_TRK*TRK_TRK;
HAMADM_HAMADMABS = fabs(TRRICCI_TRRICCI) + fabs(TRKK_TRKK) +
- TRK_TRK*TRK_TRK
+ TRK_TRK*TRK_TRK;
#endif
--- StripMime Report -- processed MIME parts ---
multipart/mixed
text/plain (text body -- kept)
text/plain (text body -- kept)
---
From schnetter at cct.lsu.edu Wed Jul 4 03:16:34 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 4 Jul 2007 10:16:34 +0200
Subject: [Developers] ADMMacros, syntax errors in C version
In-Reply-To: <20070704074831.GJ12161@peterpan.ap.op.sissa.it>
References: <20070704074831.GJ12161@peterpan.ap.op.sissa.it>
Message-ID: <26C6F3DA-9774-4EC5-9544-85813F3F999B@cct.lsu.edu>
On Jul 4, 2007, at 09:48:31, Frank L?ffler wrote:
> Hi,
>
> this patch fixes two missing ";" in the C version.
Frank,
thanks for the correction. I have applied your patch.
The fact that this code did not compile before indicates that the C
version of the macros has not yet been thoroughly tested. You should
be very careful if you want to use it. Historically, only the
Fortran version has of ADMMacros been used.
The code in ADMMacros is hand-written and therefore tends to contain
errors. These days, many people autogenerate code using a variety of
systems based on Maple or Mathematica; I'm sure you know Kranc
, and there are other,
similar systems. We (the LSU group) recently implemented our
harmonic formulation of the Einstein equations using Maple directly.
Generating code automatically also has certain other advantages. For
example, one can perform high-level optimisations of the code
depending on the machine for which one generates code. This may
become important in the future as machines have more processors
(cores) and/or less memory per node. With hand-written code these
optimisations need to be applied manually, while a code-generation
system can generate the corresponding optimisations automatically.
If one wanted e.g. to use or to experiment with multi-threading or
OpenMP, which can potentially save a significant amount of memory,
one would have to change only a few lines of Kranc to generate the
corresponding directives. This will allow much faster experiments
than manually annotating all existing loops in a production code,
probably protected by #ifdef statements to be able to switch forth
and back.
-erik
--
Erik Schnetter
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from www.keyserver.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070704/b2914631/attachment.bin
From denis.pollney at aei.mpg.de Wed Jul 4 03:31:20 2007
From: denis.pollney at aei.mpg.de (Denis Pollney)
Date: Wed, 04 Jul 2007 10:31:20 +0200
Subject: [Developers] ADMMacros, syntax errors in C version
In-Reply-To: <26C6F3DA-9774-4EC5-9544-85813F3F999B@cct.lsu.edu>
References: <20070704074831.GJ12161@peterpan.ap.op.sissa.it>
<26C6F3DA-9774-4EC5-9544-85813F3F999B@cct.lsu.edu>
Message-ID: <1183537880.30972.36.camel@x41>
On Wed, 2007-07-04 at 10:16 +0200, Erik Schnetter wrote:
> On Jul 4, 2007, at 09:48:31, Frank L?ffler wrote:
>
> > Hi,
> >
> > this patch fixes two missing ";" in the C version.
>
> Frank,
>
> thanks for the correction. I have applied your patch.
>
> The fact that this code did not compile before indicates that the C
> version of the macros has not yet been thoroughly tested. You should
> be very careful if you want to use it. Historically, only the
> Fortran version has of ADMMacros been used.
There are a couple of places where the C versions of the macros are
simply wrong. I have the impression that at some point in the very
early history of the code, when they were experimenting with things
like how to finite difference the advection terms and how the
constraints are added into the BSSN, they stopped maintaining both
versions of the macros simultaneously.
If you really need C macros, I agree with Erik that it's probably
easier to start from scratch than to go through each macro and
check that the C and Fortran versions are compatible.
Denis.
--
----------------------------------------------------------------------
Denis Pollney office: +49-331-567-7623
Max-Planck-Institut fuer Gravitationsphysik mobile: +49-170-302-3132
Albert-Einstein-Institut, Am Muehlenberg 1, D-14476, Golm, Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070704/f6a97ccc/attachment.bin
From frank.loeffler at aei.mpg.de Wed Jul 4 04:15:25 2007
From: frank.loeffler at aei.mpg.de (Frank =?utf-8?Q?L=C3=B6ffler?=)
Date: Wed, 4 Jul 2007 11:15:25 +0200
Subject: [Developers] ADMMacros, syntax errors in C version
In-Reply-To: <1183537880.30972.36.camel@x41>
References: <20070704074831.GJ12161@peterpan.ap.op.sissa.it>
<26C6F3DA-9774-4EC5-9544-85813F3F999B@cct.lsu.edu>
<1183537880.30972.36.camel@x41>
Message-ID: <20070704091524.GP12161@peterpan.ap.op.sissa.it>
On Wed, Jul 04, 2007 at 10:31:20AM +0200, Denis Pollney wrote:
> There are a couple of places where the C versions of the macros are
> simply wrong.
I know that those errors mean that nobody used them at all yet. I would
only use them to debug some things, but maybe I am really better off by
using Fortran code for that.
On the other hand, _some_ of the macros are used, also by C code.
What can we do to improve the situation? We could
a) remove the code, which is wrong
b) correct the wrong code
c) rething the whole Macros
c) might be the best for the long term, but for a) and b) we have to
identify the wrong code first. Can you point at some places?
Frank
From schnetter at cct.lsu.edu Wed Jul 4 04:42:49 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 4 Jul 2007 11:42:49 +0200
Subject: [Developers] ADMMacros, syntax errors in C version
In-Reply-To: <20070704091524.GP12161@peterpan.ap.op.sissa.it>
References: <20070704074831.GJ12161@peterpan.ap.op.sissa.it>
<26C6F3DA-9774-4EC5-9544-85813F3F999B@cct.lsu.edu>
<1183537880.30972.36.camel@x41>
<20070704091524.GP12161@peterpan.ap.op.sissa.it>
Message-ID: <7A2B2288-DB6F-4487-AA82-F002D1647247@cct.lsu.edu>
On Jul 4, 2007, at 11:15:25, Frank L?ffler wrote:
> On Wed, Jul 04, 2007 at 10:31:20AM +0200, Denis Pollney wrote:
>> There are a couple of places where the C versions of the macros are
>> simply wrong.
>
> I know that those errors mean that nobody used them at all yet. I
> would
> only use them to debug some things, but maybe I am really better
> off by
> using Fortran code for that.
> On the other hand, _some_ of the macros are used, also by C code.
Where is that? That is, which C thorn uses these macros?
-erik
--
Erik Schnetter
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from www.keyserver.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070704/29329a16/attachment.bin
From frank.loeffler at aei.mpg.de Wed Jul 4 04:56:28 2007
From: frank.loeffler at aei.mpg.de (Frank =?utf-8?Q?L=C3=B6ffler?=)
Date: Wed, 4 Jul 2007 11:56:28 +0200
Subject: [Developers] ADMMacros, syntax errors in C version
In-Reply-To: <7A2B2288-DB6F-4487-AA82-F002D1647247@cct.lsu.edu>
References: <20070704074831.GJ12161@peterpan.ap.op.sissa.it>
<26C6F3DA-9774-4EC5-9544-85813F3F999B@cct.lsu.edu>
<1183537880.30972.36.camel@x41>
<20070704091524.GP12161@peterpan.ap.op.sissa.it>
<7A2B2288-DB6F-4487-AA82-F002D1647247@cct.lsu.edu>
Message-ID: <20070704095628.GU12161@peterpan.ap.op.sissa.it>
On Wed, Jul 04, 2007 at 11:42:49AM +0200, Erik Schnetter wrote:
> Where is that? That is, which C thorn uses these macros?
at least:
AEIDevelopment/ADMMass
CactusEinstein/ADMAnalysis
Whisky_Dev/Whisky_SSIVP
Frank
From schnetter at cct.lsu.edu Wed Jul 4 05:12:50 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 4 Jul 2007 12:12:50 +0200
Subject: [Developers] ADMMacros, syntax errors in C version
In-Reply-To: <20070704095628.GU12161@peterpan.ap.op.sissa.it>
References: <20070704074831.GJ12161@peterpan.ap.op.sissa.it>
<26C6F3DA-9774-4EC5-9544-85813F3F999B@cct.lsu.edu>
<1183537880.30972.36.camel@x41>
<20070704091524.GP12161@peterpan.ap.op.sissa.it>
<7A2B2288-DB6F-4487-AA82-F002D1647247@cct.lsu.edu>
<20070704095628.GU12161@peterpan.ap.op.sissa.it>
Message-ID:
On Jul 4, 2007, at 11:56:28, Frank L?ffler wrote:
> On Wed, Jul 04, 2007 at 11:42:49AM +0200, Erik Schnetter wrote:
>> Where is that? That is, which C thorn uses these macros?
>
> at least:
>
> AEIDevelopment/ADMMass
> CactusEinstein/ADMAnalysis
Indeed; this calculates the Ricci tensor using the C version of the
macros.
> Whisky_Dev/Whisky_SSIVP
-erik
--
Erik Schnetter
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from www.keyserver.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070704/79d0a9e7/attachment.bin
From denis.pollney at aei.mpg.de Wed Jul 4 05:16:23 2007
From: denis.pollney at aei.mpg.de (Denis Pollney)
Date: Wed, 04 Jul 2007 12:16:23 +0200
Subject: [Developers] ADMMacros, syntax errors in C version
In-Reply-To: <20070704095628.GU12161@peterpan.ap.op.sissa.it>
References: <20070704074831.GJ12161@peterpan.ap.op.sissa.it>
<26C6F3DA-9774-4EC5-9544-85813F3F999B@cct.lsu.edu>
<1183537880.30972.36.camel@x41>
<20070704091524.GP12161@peterpan.ap.op.sissa.it>
<7A2B2288-DB6F-4487-AA82-F002D1647247@cct.lsu.edu>
<20070704095628.GU12161@peterpan.ap.op.sissa.it>
Message-ID: <1183544183.30972.50.camel@x41>
On Wed, 2007-07-04 at 11:56 +0200, Frank L?ffler wrote:
> On Wed, Jul 04, 2007 at 11:42:49AM +0200, Erik Schnetter wrote:
> > Where is that? That is, which C thorn uses these macros?
>
> at least:
>
> AEIDevelopment/ADMMass
> CactusEinstein/ADMAnalysis
> Whisky_Dev/Whisky_SSIVP
I seem to remember that the worst offenders had to do with
advective terms and whether they were applied consistently and
correctly, and mostly in the evolution equations.
I think the standard things, like K_ij or the inverse of the
metric, are likely okay. So if the thorns are just doing
analysis, they might get away with it. Worth a check, though.
Once you start using the source equations, eg. to calculate
'd/dt K_ij' or anything to do with Gamma~, then I'd be more
worried.
Denis.
--
----------------------------------------------------------------------
Denis Pollney office: +49-331-567-7623
Max-Planck-Institut fuer Gravitationsphysik mobile: +49-170-302-3132
Albert-Einstein-Institut, Am Muehlenberg 1, D-14476, Golm, Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070704/d904a3df/attachment.bin
From claudio at das.inpe.br Wed Jul 4 10:46:48 2007
From: claudio at das.inpe.br (claudio at das.inpe.br)
Date: Wed, 4 Jul 2007 12:46:48 -0300
Subject: [Developers] Contents of Developers Digest
In-Reply-To:
References:
Message-ID: <1183564008.468bc0e82bd19@webmail.inpe.br>
Hi, Erik.
I have good news. When I sent that message, the executable file wasn't been
generated. That situation hadn't solution with my old linux distribution and its
problems !! ... So, I've decided to install Fedora Core 6 in my machine, and I
did it. By now, my system works very well. I can compile Cactus making:
claudiob> gmake Bench_BSSN_PUGH_single F90=gfotran
The Result is the executable is generated and works correctly.
Thank you for your suport.
My best regards,
Claudio.
> Today's Topics:
>
> 1. Bugs ?? -- config file. (claudio at das.inpe.br)
> 2. Re: Bugs ?? (Erik Schnetter)
> 3. ADMMacros, syntax errors in C version (Frank L?ffler)
> 4. Re: ADMMacros, syntax errors in C version (Erik Schnetter)
> 5. Re: ADMMacros, syntax errors in C version (Denis Pollney)
> 6. Re: ADMMacros, syntax errors in C version (Frank L?ffler)
> 7. Re: ADMMacros, syntax errors in C version (Erik Schnetter)
> 8. Re: ADMMacros, syntax errors in C version (Frank L?ffler)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 18 Jun 2007 14:11:24 -0300
> From: claudio at das.inpe.br
> Subject: [Developers] Bugs ?? -- config file.
> To: developers at cactuscode.org
> Message-ID: <1182186684.4676bcbc3ef6d at webmail.inpe.br>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
> My configuration file ...
> ________________________________________________________________________
> Cactus - version: 4.0.b16
> if test ! -r
>
"/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/Bench_BSSN_PUGH_single/config-info";
> then \
> echo ""; \
> echo "Error reconfiguring 'Bench_BSSN_PUGH_single': configuration is
> incomplete."; \
> echo "Use 'gmake Bench_BSSN_PUGH_single-reconfig' to configure the
> configuration."; \
> exit 2; \
> elif ! head -n 1
> /home/claudiob/DOUTORADO/CACTUS/Cactus/configs/Bench_BSSN_PUGH_single/config-info
> | grep -q '# CONFIGURATION'; then \
> echo "Error reconfiguring 'Bench_BSSN_PUGH_single': unrecognized
> config-info
> file format" ; \
> echo "This probably means that the Cactus config-info file format has
> changed"; \
> echo "since this configuration was last configured. You will have to
> freshly"; \
> echo "configure the configuration with"; \
> echo " gmake Bench_BSSN_PUGH_single-config OPTION1=VALUE1 OPTION2=VALUE2
> ..."; \
> echo "Note that this will overwrite all of this configuration's current";
> \
> echo "configuration options. See the config-info file"; \
> echo "
>
/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/Bench_BSSN_PUGH_single/config-info";
> \
> echo "to see what these are."; \
> exit 2; \
> fi; \
> if ( perl -s lib/make/setup_configuration.pl
>
-config_file=/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/Bench_BSSN_PUGH_single/config-info
> Bench_BSSN_PUGH_single) ; then : ; else \
> echo "" ; \
> echo "Error reconfiguring Bench_BSSN_PUGH_single-reconfig" ;
>
> \
> rm -f
>
"/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/Bench_BSSN_PUGH_single/config-data/cctk_Config.h";\
> exit 2 ; \
> fi ; \
> echo
> ________________________________________________________________________ ; \
> if test "x"yes"" = "xno" ; then \
> gmake Bench_BSSN_PUGH_single WARN=; \
> else \
> echo Use 'gmake Bench_BSSN_PUGH_single' to build the configuration. ; \
> fi
> Reconfiguring Bench_BSSN_PUGH_single.
> Adding configuration options from
>
'/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/Bench_BSSN_PUGH_single/config-info'...
> End of options from
>
'/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/Bench_BSSN_PUGH_single/config-info'.
> creating cache ./config.cache
> checking host system type... x86_64-unknown-linux-gnu
> Setting FPP to /lib/cpp
> Setting FPPFLAGS to -traditional
> checking whether make sets ${MAKE}... yes
> checking for gcc... gcc
> checking whether the C compiler (gcc ) works... yes
> checking whether the C compiler (gcc ) is a cross-compiler... no
> checking whether we are using GNU C... yes
> checking for c++... c++
> checking whether the C++ compiler (c++ ) works... yes
> checking whether the C++ compiler (c++ ) is a cross-compiler... no
> checking whether we are using GNU C++... yes
> checking for ranlib... ranlib
> checking for cpp... /lib/cpp
> checking for perl... perl
> checking for f90... f90
> checking for f77... f77
> checking for ar... ar
> checking for mkdir... mkdir
> Setting CACHELINE_BYTES to 64
> Setting CACHE_SIZE to 2048*1024 bytes
> checking how to run the C preprocessor... /lib/cpp
> checking for ANSI C header files... yes
> checking whether byte ordering is bigendian... no
> checking size of long long... 8
> checking size of long int... 8
> checking size of int... 4
> checking size of short int... 2
> checking size of long double... 16
> checking size of double... 8
> checking size of float... 4
> checking size of char *... 8
> checking for the null device... /dev/null
> checking for gethostbyname... yes
> checking if mode_t is defined... yes
> checking for availability of gettimeofday timing... yes
> checking if gettimeofday needs timezone... yes
> checking for availability of getrusage timing... yes
> checking for availability of _ftime timing... no
> checking for time.h... yes
> checking for sys/time.h... yes
> checking for sys/types.h... yes
> checking for unistd.h... yes
> checking for string.h... yes
> checking for assert.h... yes
> checking for sys/stat.h... yes
> checking for getopt.h... yes
> checking for dirent.h... yes
> checking for regex.h... yes
> checking for sys/filio.h... no
> checking for sys/ioctl.h... yes
> checking for sys/socket.h... yes
> checking for netinet/in.h... yes
> checking for netdb.h... yes
> checking for arpa/inet.h... yes
> checking for winsock2.h... no
> checking for crypt.h... yes
> checking for signal.h... yes
> checking whether time.h and sys/time.h may both be included... yes
> checking if socklen_t is defined... yes
> checking if SOCKET is defined... no
> checking if __int64 is defined... no
> checking for vector... yes
> checking for vector.h... yes
> checking for getopt_long_only... yes
> checking for working const... yes
> checking for inline... inline
> checking for C restrict... __restrict__
> checking for C++ restrict... __restrict__
> checking for C bool... no
> checking for CXX bool... yes
> checking for crypt... no
> checking for crypt in library crypt... yes
> checking for finite... yes
> checking for isnan... yes
> checking for mkstemp... yes
> checking for va_copy... yes
> creating cctk_Archdefs.h
> creating make.arch.defn
> creating cctk_Extradefs.h
> creating make.extra.defn
> cctk_Archdefs.h is unchanged
> make.arch.defn is unchanged
> cctk_Extradefs.h is unchanged
> make.extra.defn is unchanged
> updating cache ./config.cache
> creating ./config.status
> creating make.config.defn
> creating make.config.deps
> creating make.config.rules
> creating cctk_Config.h
> cctk_Config.h is unchanged
> Determining number of fortran underscores...
> Compiling test file with f90 -align -w95 ...
> Lowercase - One trailing underscore
> Compiling test file with f90 -align -w95 ...
> Lowercase - One trailing underscore
> ________________________________________________________________________
> Use gmake Bench_BSSN_PUGH_single to build the configuration.
> ________________________________________________________________________
>
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 23 Jun 2007 14:37:31 -0500
> From: Erik Schnetter
> Subject: Re: [Developers] Bugs ??
> To: developers at cactuscode.org
> Message-ID:
> Content-Type: text/plain; charset="us-ascii"
>
> On Jun 18, 2007, at 11:53:12, claudio at das.inpe.br wrote:
>
> > c++ -o
> > "/home/claudiob/DOUTORADO/CACTUS/Cactus/exe/
> > cactus_Bench_BSSN_PUGH_single" -Qy
> > /usr/lib/icrt.link
> > "/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
> > Bench_BSSN_PUGH_single/datestamp.o"
> > -L/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
> > Bench_BSSN_PUGH_single/lib
> > -lthorn_Cactus -lthorn_CactusBindings -lthorn_BSSN_MoL -
> > lthorn_StaticConformal
> > -lthorn_SpaceMask -lthorn_ADMBase -lthorn_CartGrid3D -lthorn_MoL
> > -lthorn_NaNChecker -lthorn_PUGHReduce -lthorn_PUGHInterp -
> > lthorn_IOBasic
> > -lthorn_Time -lthorn_SymBase -lthorn_IOUtil -lthorn_CoordGauge -
> > lthorn_CoordBase
> > -lthorn_Boundary -lthorn_ADMMacros -lthorn_ADMCoupling -
> > lthorn_PUGHSlab
> > -lthorn_PUGH -lthorn_Cactus -lthorn_CactusBindings -L/usr/lib -
> > lcrypt -lifcore
> > -limf -lsvml -lm
> > gmake[1]: Leaving directory `/home/claudiob/DOUTORADO/CACTUS/Cactus'
>
> Claudio,
>
> this output looks as if the executable has been successfully
> generated. At least I do not see the error message any more which
> you showed in your first email. Do you have an executable in the
> "exe" directory?
>
> -erik
>
> --
> Erik Schnetter
>
> My email is as private as my paper mail. I therefore support encrypting
> and signing email messages. Get my PGP key from www.keyserver.net.
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: PGP.sig
> Type: application/pgp-signature
> Size: 186 bytes
> Desc: This is a digitally signed message part
> Url :
>
http://www.cactuscode.org/pipermail/developers/attachments/20070623/43490d99/attachment-0001.bin
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 4 Jul 2007 09:48:31 +0200
> From: Frank L?ffler
> Subject: [Developers] ADMMacros, syntax errors in C version
> To: patches at cactuscode.org
> Message-ID: <20070704074831.GJ12161 at peterpan.ap.op.sissa.it>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> this patch fixes two missing ";" in the C version.
>
> Frank
>
>
> Index: ADMMacros/src/macro/HAMADM_guts.h
> ===================================================================
> RCS file: /cactusdevcvs/CactusEinstein/ADMMacros/src/macro/HAMADM_guts.h,v
> retrieving revision 1.7
> diff -u -r1.7 HAMADM_guts.h
> --- ADMMacros/src/macro/HAMADM_guts.h 18 Nov 2004 14:18:24 -0000 1.7
> +++ ADMMacros/src/macro/HAMADM_guts.h 4 Jul 2007 07:38:35 -0000
> @@ -27,9 +27,9 @@
>
> #ifdef CCODE
>
> - HAMADM_HAMADM = TRRICCI_TRRICCI - TRKK_TRKK + TRK_TRK*TRK_TRK
> + HAMADM_HAMADM = TRRICCI_TRRICCI - TRKK_TRKK + TRK_TRK*TRK_TRK;
> HAMADM_HAMADMABS = fabs(TRRICCI_TRRICCI) + fabs(TRKK_TRKK) +
> - TRK_TRK*TRK_TRK
> + TRK_TRK*TRK_TRK;
>
> #endif
>
>
>
> --- StripMime Report -- processed MIME parts ---
> multipart/mixed
> text/plain (text body -- kept)
> text/plain (text body -- kept)
> ---
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 4 Jul 2007 10:16:34 +0200
> From: Erik Schnetter
> Subject: Re: [Developers] ADMMacros, syntax errors in C version
> To: developers at cactuscode.org
> Message-ID: <26C6F3DA-9774-4EC5-9544-85813F3F999B at cct.lsu.edu>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Jul 4, 2007, at 09:48:31, Frank L?ffler wrote:
>
> > Hi,
> >
> > this patch fixes two missing ";" in the C version.
>
> Frank,
>
> thanks for the correction. I have applied your patch.
>
> The fact that this code did not compile before indicates that the C
> version of the macros has not yet been thoroughly tested. You should
> be very careful if you want to use it. Historically, only the
> Fortran version has of ADMMacros been used.
>
> The code in ADMMacros is hand-written and therefore tends to contain
> errors. These days, many people autogenerate code using a variety of
> systems based on Maple or Mathematica; I'm sure you know Kranc
> , and there are other,
> similar systems. We (the LSU group) recently implemented our
> harmonic formulation of the Einstein equations using Maple directly.
>
> Generating code automatically also has certain other advantages. For
> example, one can perform high-level optimisations of the code
> depending on the machine for which one generates code. This may
> become important in the future as machines have more processors
> (cores) and/or less memory per node. With hand-written code these
> optimisations need to be applied manually, while a code-generation
> system can generate the corresponding optimisations automatically.
>
> If one wanted e.g. to use or to experiment with multi-threading or
> OpenMP, which can potentially save a significant amount of memory,
> one would have to change only a few lines of Kranc to generate the
> corresponding directives. This will allow much faster experiments
> than manually annotating all existing loops in a production code,
> probably protected by #ifdef statements to be able to switch forth
> and back.
>
> -erik
>
> --
> Erik Schnetter
>
> My email is as private as my paper mail. I therefore support encrypting
> and signing email messages. Get my PGP key from www.keyserver.net.
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: PGP.sig
> Type: application/pgp-signature
> Size: 186 bytes
> Desc: This is a digitally signed message part
> Url :
>
http://www.cactuscode.org/pipermail/developers/attachments/20070704/b2914631/attachment-0001.bin
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 04 Jul 2007 10:31:20 +0200
> From: Denis Pollney
> Subject: Re: [Developers] ADMMacros, syntax errors in C version
> To: developers at cactuscode.org
> Message-ID: <1183537880.30972.36.camel at x41>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wed, 2007-07-04 at 10:16 +0200, Erik Schnetter wrote:
> > On Jul 4, 2007, at 09:48:31, Frank L?ffler wrote:
> >
> > > Hi,
> > >
> > > this patch fixes two missing ";" in the C version.
> >
> > Frank,
> >
> > thanks for the correction. I have applied your patch.
> >
> > The fact that this code did not compile before indicates that the C
> > version of the macros has not yet been thoroughly tested. You should
> > be very careful if you want to use it. Historically, only the
> > Fortran version has of ADMMacros been used.
>
> There are a couple of places where the C versions of the macros are
> simply wrong. I have the impression that at some point in the very
> early history of the code, when they were experimenting with things
> like how to finite difference the advection terms and how the
> constraints are added into the BSSN, they stopped maintaining both
> versions of the macros simultaneously.
>
> If you really need C macros, I agree with Erik that it's probably
> easier to start from scratch than to go through each macro and
> check that the C and Fortran versions are compatible.
>
> Denis.
>
> --
> ----------------------------------------------------------------------
> Denis Pollney office: +49-331-567-7623
> Max-Planck-Institut fuer Gravitationsphysik mobile: +49-170-302-3132
> Albert-Einstein-Institut, Am Muehlenberg 1, D-14476, Golm, Germany
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: This is a digitally signed message part
> Url :
>
http://www.cactuscode.org/pipermail/developers/attachments/20070704/f6a97ccc/attachment-0001.bin
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 4 Jul 2007 11:15:25 +0200
> From: Frank L?ffler
> Subject: Re: [Developers] ADMMacros, syntax errors in C version
> To: developers at cactuscode.org
> Message-ID: <20070704091524.GP12161 at peterpan.ap.op.sissa.it>
> Content-Type: text/plain; charset=utf-8
>
> On Wed, Jul 04, 2007 at 10:31:20AM +0200, Denis Pollney wrote:
> > There are a couple of places where the C versions of the macros are
> > simply wrong.
>
> I know that those errors mean that nobody used them at all yet. I would
> only use them to debug some things, but maybe I am really better off by
> using Fortran code for that.
> On the other hand, _some_ of the macros are used, also by C code.
>
> What can we do to improve the situation? We could
> a) remove the code, which is wrong
> b) correct the wrong code
> c) rething the whole Macros
>
> c) might be the best for the long term, but for a) and b) we have to
> identify the wrong code first. Can you point at some places?
>
> Frank
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 4 Jul 2007 11:42:49 +0200
> From: Erik Schnetter
> Subject: Re: [Developers] ADMMacros, syntax errors in C version
> To: developers at cactuscode.org
> Message-ID: <7A2B2288-DB6F-4487-AA82-F002D1647247 at cct.lsu.edu>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Jul 4, 2007, at 11:15:25, Frank L?ffler wrote:
>
> > On Wed, Jul 04, 2007 at 10:31:20AM +0200, Denis Pollney wrote:
> >> There are a couple of places where the C versions of the macros are
> >> simply wrong.
> >
> > I know that those errors mean that nobody used them at all yet. I
> > would
> > only use them to debug some things, but maybe I am really better
> > off by
> > using Fortran code for that.
> > On the other hand, _some_ of the macros are used, also by C code.
>
> Where is that? That is, which C thorn uses these macros?
>
> -erik
>
> --
> Erik Schnetter
>
> My email is as private as my paper mail. I therefore support encrypting
> and signing email messages. Get my PGP key from www.keyserver.net.
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: PGP.sig
> Type: application/pgp-signature
> Size: 186 bytes
> Desc: This is a digitally signed message part
> Url :
>
http://www.cactuscode.org/pipermail/developers/attachments/20070704/29329a16/attachment-0001.bin
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 4 Jul 2007 11:56:28 +0200
> From: Frank L?ffler
> Subject: Re: [Developers] ADMMacros, syntax errors in C version
> To: developers at cactuscode.org
> Message-ID: <20070704095628.GU12161 at peterpan.ap.op.sissa.it>
> Content-Type: text/plain; charset=utf-8
>
> On Wed, Jul 04, 2007 at 11:42:49AM +0200, Erik Schnetter wrote:
> > Where is that? That is, which C thorn uses these macros?
>
> at least:
>
> AEIDevelopment/ADMMass
> CactusEinstein/ADMAnalysis
> Whisky_Dev/Whisky_SSIVP
>
> Frank
>
>
>
> ------------------------------
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>
>
> End of Developers Digest, Vol 45, Issue 1
> *****************************************
>
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
From schnetter at cct.lsu.edu Fri Jul 6 07:57:24 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Fri, 6 Jul 2007 14:57:24 +0200
Subject: [Developers] Infrastructure for initial data setup
Message-ID: <106FBFC4-A024-40F5-8BF8-C0B70083FCD3@cct.lsu.edu>
There is currently no infrastructure in Cactus which helps decide how
to set up initial data. With mesh refinement, there are several
incompatible ways in which initial data thorns can set up initial
data. Depending on this, evolution thorns may have to adapt, or mesh
refinement drivers may schedule evolution differently.
This lack of infrastructure leads to problems, since initial data
thorns, evolution methods, and the Carpet mesh refinement driver are
not well coordinated. The user who writes parameter files has to
know the behaviour of each of these, and then choose parameters so
that these pieces work together correctly. There is no entity in
Cactus which knows how initial data should be set up, and which could
provide error checking. This leads to inconsistencies which are
difficult to detect.
I suggest to create a new thorn CactusBase/InitBase. It would
contain the following README:
----------------------------------------
Specify how initial data are to be set up. There are three
possibilities:
1. The initial data thorn sets up data on one time level, while other
time levels are scratch space. The time evolution method must
start up from a single time level. (This is the default.)
2. The initial data thorn sets up data on exactly one time level, and
is called once for each active time level. (This means that the
initial data thorn can only access the current time level.)
3. The initial data thorn sets up data on all active time levels.
(This makes it necessary that the initial data thorn checks the
number of active time levels.)
----------------------------------------
Apart from this README, thorn InitBase would contain one restricted
parameter "initial_data_setup_method" which allows users to choose
the desired behaviour in the parameter file. All initial data
thorns, evolution methods, and drivers then have to check the value
of this parameter, and either adapt their behaviour or signal an error.
-erik
--
Erik Schnetter
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from www.keyserver.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: InitBase.tar.gz
Type: application/x-gzip
Size: 2996 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070706/090713e5/attachment-0001.gz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070706/090713e5/attachment-0001.bin
From baiotti at aei.mpg.de Fri Jul 6 10:48:33 2007
From: baiotti at aei.mpg.de (Luca Baiotti)
Date: Fri, 06 Jul 2007 17:48:33 +0200
Subject: [Developers] Infrastructure for initial data setup
In-Reply-To: <106FBFC4-A024-40F5-8BF8-C0B70083FCD3@cct.lsu.edu>
References: <106FBFC4-A024-40F5-8BF8-C0B70083FCD3@cct.lsu.edu>
Message-ID: <468E6451.5050805@aei.mpg.de>
Hi,
your proposal seems a good idea to me.
Luca.
Erik Schnetter wrote:
> There is currently no infrastructure in Cactus which helps decide how to
> set up initial data. With mesh refinement, there are several
> incompatible ways in which initial data thorns can set up initial data.
> Depending on this, evolution thorns may have to adapt, or mesh
> refinement drivers may schedule evolution differently.
>
> This lack of infrastructure leads to problems, since initial data
> thorns, evolution methods, and the Carpet mesh refinement driver are not
> well coordinated. The user who writes parameter files has to know the
> behaviour of each of these, and then choose parameters so that these
> pieces work together correctly. There is no entity in Cactus which
> knows how initial data should be set up, and which could provide error
> checking. This leads to inconsistencies which are difficult to detect.
>
> I suggest to create a new thorn CactusBase/InitBase. It would contain
> the following README:
>
> ----------------------------------------
> Specify how initial data are to be set up. There are three
> possibilities:
>
> 1. The initial data thorn sets up data on one time level, while other
> time levels are scratch space. The time evolution method must
> start up from a single time level. (This is the default.)
>
> 2. The initial data thorn sets up data on exactly one time level, and
> is called once for each active time level. (This means that the
> initial data thorn can only access the current time level.)
>
> 3. The initial data thorn sets up data on all active time levels.
> (This makes it necessary that the initial data thorn checks the
> number of active time levels.)
> ----------------------------------------
>
> Apart from this README, thorn InitBase would contain one restricted
> parameter "initial_data_setup_method" which allows users to choose the
> desired behaviour in the parameter file. All initial data thorns,
> evolution methods, and drivers then have to check the value of this
> parameter, and either adapt their behaviour or signal an error.
>
> -erik
From schnetter at cct.lsu.edu Sun Jul 8 14:03:30 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sun, 8 Jul 2007 21:03:30 +0200
Subject: [Developers] Contents of Developers Digest
In-Reply-To: <1183564008.468bc0e82bd19@webmail.inpe.br>
References:
<1183564008.468bc0e82bd19@webmail.inpe.br>
Message-ID:
Hi Claudo,
congratulations. That is good to hear.
-erik
On Jul 4, 2007, at 17:46:48, claudio at das.inpe.br wrote:
> Hi, Erik.
>
> I have good news. When I sent that message, the executable file
> wasn't been
> generated. That situation hadn't solution with my old linux
> distribution and its
> problems !! ... So, I've decided to install Fedora Core 6 in my
> machine, and I
> did it. By now, my system works very well. I can compile Cactus
> making:
>
> claudiob> gmake Bench_BSSN_PUGH_single F90=gfotran
>
> The Result is the executable is generated and works correctly.
>
> Thank you for your suport.
> My best regards,
>
> Claudio.
>
>
>
>
>> Today's Topics:
>>
>> 1. Bugs ?? -- config file. (claudio at das.inpe.br)
>> 2. Re: Bugs ?? (Erik Schnetter)
>> 3. ADMMacros, syntax errors in C version (Frank L?ffler)
>> 4. Re: ADMMacros, syntax errors in C version (Erik Schnetter)
>> 5. Re: ADMMacros, syntax errors in C version (Denis Pollney)
>> 6. Re: ADMMacros, syntax errors in C version (Frank L?ffler)
>> 7. Re: ADMMacros, syntax errors in C version (Erik Schnetter)
>> 8. Re: ADMMacros, syntax errors in C version (Frank L?ffler)
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>> Message: 1
>> Date: Mon, 18 Jun 2007 14:11:24 -0300
>> From: claudio at das.inpe.br
>> Subject: [Developers] Bugs ?? -- config file.
>> To: developers at cactuscode.org
>> Message-ID: <1182186684.4676bcbc3ef6d at webmail.inpe.br>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>
>> My configuration file ...
>> _____________________________________________________________________
>> ___
>> Cactus - version: 4.0.b16
>> if test ! -r
>>
> "/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
> Bench_BSSN_PUGH_single/config-info";
>> then \
>> echo ""; \
>> echo "Error reconfiguring 'Bench_BSSN_PUGH_single':
>> configuration is
>> incomplete."; \
>> echo "Use 'gmake Bench_BSSN_PUGH_single-reconfig' to configure the
>> configuration."; \
>> exit 2; \
>> elif ! head -n 1
>> /home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
>> Bench_BSSN_PUGH_single/config-info
>> | grep -q '# CONFIGURATION'; then \
>> echo "Error reconfiguring 'Bench_BSSN_PUGH_single': unrecognized
>> config-info
>> file format" ; \
>> echo "This probably means that the Cactus config-info file
>> format has
>> changed"; \
>> echo "since this configuration was last configured. You will
>> have to
>> freshly"; \
>> echo "configure the configuration with"; \
>> echo " gmake Bench_BSSN_PUGH_single-config OPTION1=VALUE1
>> OPTION2=VALUE2
>> ..."; \
>> echo "Note that this will overwrite all of this configuration's
>> current";
>> \
>> echo "configuration options. See the config-info file"; \
>> echo "
>>
> /home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
> Bench_BSSN_PUGH_single/config-info";
>> \
>> echo "to see what these are."; \
>> exit 2; \
>> fi; \
>> if ( perl -s lib/make/setup_configuration.pl
>>
> -config_file=/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
> Bench_BSSN_PUGH_single/config-info
>> Bench_BSSN_PUGH_single) ; then : ; else \
>> echo
>> "" ; \
>> echo "Error reconfiguring Bench_BSSN_PUGH_single-
>> reconfig" ;
>>
>> \
>> rm -f
>>
> "/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
> Bench_BSSN_PUGH_single/config-data/cctk_Config.h";\
>> exit
>> 2 ; \
>>
>> fi ; \
>> echo
>> _____________________________________________________________________
>> ___ ; \
>> if test "x"yes"" = "xno" ; then \
>> gmake Bench_BSSN_PUGH_single WARN=; \
>> else \
>> echo Use 'gmake Bench_BSSN_PUGH_single' to build the
>> configuration. ; \
>> fi
>> Reconfiguring Bench_BSSN_PUGH_single.
>> Adding configuration options from
>>
> '/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
> Bench_BSSN_PUGH_single/config-info'...
>> End of options from
>>
> '/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
> Bench_BSSN_PUGH_single/config-info'.
>> creating cache ./config.cache
>> checking host system type... x86_64-unknown-linux-gnu
>> Setting FPP to /lib/cpp
>> Setting FPPFLAGS to -traditional
>> checking whether make sets ${MAKE}... yes
>> checking for gcc... gcc
>> checking whether the C compiler (gcc ) works... yes
>> checking whether the C compiler (gcc ) is a cross-compiler... no
>> checking whether we are using GNU C... yes
>> checking for c++... c++
>> checking whether the C++ compiler (c++ ) works... yes
>> checking whether the C++ compiler (c++ ) is a cross-compiler... no
>> checking whether we are using GNU C++... yes
>> checking for ranlib... ranlib
>> checking for cpp... /lib/cpp
>> checking for perl... perl
>> checking for f90... f90
>> checking for f77... f77
>> checking for ar... ar
>> checking for mkdir... mkdir
>> Setting CACHELINE_BYTES to 64
>> Setting CACHE_SIZE to 2048*1024 bytes
>> checking how to run the C preprocessor... /lib/cpp
>> checking for ANSI C header files... yes
>> checking whether byte ordering is bigendian... no
>> checking size of long long... 8
>> checking size of long int... 8
>> checking size of int... 4
>> checking size of short int... 2
>> checking size of long double... 16
>> checking size of double... 8
>> checking size of float... 4
>> checking size of char *... 8
>> checking for the null device... /dev/null
>> checking for gethostbyname... yes
>> checking if mode_t is defined... yes
>> checking for availability of gettimeofday timing... yes
>> checking if gettimeofday needs timezone... yes
>> checking for availability of getrusage timing... yes
>> checking for availability of _ftime timing... no
>> checking for time.h... yes
>> checking for sys/time.h... yes
>> checking for sys/types.h... yes
>> checking for unistd.h... yes
>> checking for string.h... yes
>> checking for assert.h... yes
>> checking for sys/stat.h... yes
>> checking for getopt.h... yes
>> checking for dirent.h... yes
>> checking for regex.h... yes
>> checking for sys/filio.h... no
>> checking for sys/ioctl.h... yes
>> checking for sys/socket.h... yes
>> checking for netinet/in.h... yes
>> checking for netdb.h... yes
>> checking for arpa/inet.h... yes
>> checking for winsock2.h... no
>> checking for crypt.h... yes
>> checking for signal.h... yes
>> checking whether time.h and sys/time.h may both be included... yes
>> checking if socklen_t is defined... yes
>> checking if SOCKET is defined... no
>> checking if __int64 is defined... no
>> checking for vector... yes
>> checking for vector.h... yes
>> checking for getopt_long_only... yes
>> checking for working const... yes
>> checking for inline... inline
>> checking for C restrict... __restrict__
>> checking for C++ restrict... __restrict__
>> checking for C bool... no
>> checking for CXX bool... yes
>> checking for crypt... no
>> checking for crypt in library crypt... yes
>> checking for finite... yes
>> checking for isnan... yes
>> checking for mkstemp... yes
>> checking for va_copy... yes
>> creating cctk_Archdefs.h
>> creating make.arch.defn
>> creating cctk_Extradefs.h
>> creating make.extra.defn
>> cctk_Archdefs.h is unchanged
>> make.arch.defn is unchanged
>> cctk_Extradefs.h is unchanged
>> make.extra.defn is unchanged
>> updating cache ./config.cache
>> creating ./config.status
>> creating make.config.defn
>> creating make.config.deps
>> creating make.config.rules
>> creating cctk_Config.h
>> cctk_Config.h is unchanged
>> Determining number of fortran underscores...
>> Compiling test file with f90 -align -w95 ...
>> Lowercase - One trailing underscore
>> Compiling test file with f90 -align -w95 ...
>> Lowercase - One trailing underscore
>> _____________________________________________________________________
>> ___
>> Use gmake Bench_BSSN_PUGH_single to build the configuration.
>> _____________________________________________________________________
>> ___
>>
>>
>> -------------------------------------------------
>> This mail sent through IMP: http://horde.org/imp/
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 23 Jun 2007 14:37:31 -0500
>> From: Erik Schnetter
>> Subject: Re: [Developers] Bugs ??
>> To: developers at cactuscode.org
>> Message-ID:
>> Content-Type: text/plain; charset="us-ascii"
>>
>> On Jun 18, 2007, at 11:53:12, claudio at das.inpe.br wrote:
>>
>>> c++ -o
>>> "/home/claudiob/DOUTORADO/CACTUS/Cactus/exe/
>>> cactus_Bench_BSSN_PUGH_single" -Qy
>>> /usr/lib/icrt.link
>>> "/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
>>> Bench_BSSN_PUGH_single/datestamp.o"
>>> -L/home/claudiob/DOUTORADO/CACTUS/Cactus/configs/
>>> Bench_BSSN_PUGH_single/lib
>>> -lthorn_Cactus -lthorn_CactusBindings -lthorn_BSSN_MoL -
>>> lthorn_StaticConformal
>>> -lthorn_SpaceMask -lthorn_ADMBase -lthorn_CartGrid3D -lthorn_MoL
>>> -lthorn_NaNChecker -lthorn_PUGHReduce -lthorn_PUGHInterp -
>>> lthorn_IOBasic
>>> -lthorn_Time -lthorn_SymBase -lthorn_IOUtil -lthorn_CoordGauge -
>>> lthorn_CoordBase
>>> -lthorn_Boundary -lthorn_ADMMacros -lthorn_ADMCoupling -
>>> lthorn_PUGHSlab
>>> -lthorn_PUGH -lthorn_Cactus -lthorn_CactusBindings -L/usr/lib -
>>> lcrypt -lifcore
>>> -limf -lsvml -lm
>>> gmake[1]: Leaving directory `/home/claudiob/DOUTORADO/CACTUS/Cactus'
>>
>> Claudio,
>>
>> this output looks as if the executable has been successfully
>> generated. At least I do not see the error message any more which
>> you showed in your first email. Do you have an executable in the
>> "exe" directory?
>>
>> -erik
>>
>> --
>> Erik Schnetter
>>
>> My email is as private as my paper mail. I therefore support
>> encrypting
>> and signing email messages. Get my PGP key from www.keyserver.net.
>>
>>
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: PGP.sig
>> Type: application/pgp-signature
>> Size: 186 bytes
>> Desc: This is a digitally signed message part
>> Url :
>>
> http://www.cactuscode.org/pipermail/developers/attachments/
> 20070623/43490d99/attachment-0001.bin
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 4 Jul 2007 09:48:31 +0200
>> From: Frank L?ffler
>> Subject: [Developers] ADMMacros, syntax errors in C version
>> To: patches at cactuscode.org
>> Message-ID: <20070704074831.GJ12161 at peterpan.ap.op.sissa.it>
>> Content-Type: text/plain; charset=utf-8
>>
>> Hi,
>>
>> this patch fixes two missing ";" in the C version.
>>
>> Frank
>>
>>
>> Index: ADMMacros/src/macro/HAMADM_guts.h
>> ===================================================================
>> RCS file: /cactusdevcvs/CactusEinstein/ADMMacros/src/macro/
>> HAMADM_guts.h,v
>> retrieving revision 1.7
>> diff -u -r1.7 HAMADM_guts.h
>> --- ADMMacros/src/macro/HAMADM_guts.h 18 Nov 2004 14:18:24 -0000 1.7
>> +++ ADMMacros/src/macro/HAMADM_guts.h 4 Jul 2007 07:38:35 -0000
>> @@ -27,9 +27,9 @@
>>
>> #ifdef CCODE
>>
>> - HAMADM_HAMADM = TRRICCI_TRRICCI - TRKK_TRKK + TRK_TRK*TRK_TRK
>> + HAMADM_HAMADM = TRRICCI_TRRICCI - TRKK_TRKK + TRK_TRK*TRK_TRK;
>> HAMADM_HAMADMABS = fabs(TRRICCI_TRRICCI) + fabs(TRKK_TRKK) +
>> - TRK_TRK*TRK_TRK
>> + TRK_TRK*TRK_TRK;
>>
>> #endif
>>
>>
>>
>> --- StripMime Report -- processed MIME parts ---
>> multipart/mixed
>> text/plain (text body -- kept)
>> text/plain (text body -- kept)
>> ---
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 4 Jul 2007 10:16:34 +0200
>> From: Erik Schnetter
>> Subject: Re: [Developers] ADMMacros, syntax errors in C version
>> To: developers at cactuscode.org
>> Message-ID: <26C6F3DA-9774-4EC5-9544-85813F3F999B at cct.lsu.edu>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> On Jul 4, 2007, at 09:48:31, Frank L?ffler wrote:
>>
>>> Hi,
>>>
>>> this patch fixes two missing ";" in the C version.
>>
>> Frank,
>>
>> thanks for the correction. I have applied your patch.
>>
>> The fact that this code did not compile before indicates that the C
>> version of the macros has not yet been thoroughly tested. You should
>> be very careful if you want to use it. Historically, only the
>> Fortran version has of ADMMacros been used.
>>
>> The code in ADMMacros is hand-written and therefore tends to contain
>> errors. These days, many people autogenerate code using a variety of
>> systems based on Maple or Mathematica; I'm sure you know Kranc
>> , and there are other,
>> similar systems. We (the LSU group) recently implemented our
>> harmonic formulation of the Einstein equations using Maple directly.
>>
>> Generating code automatically also has certain other advantages. For
>> example, one can perform high-level optimisations of the code
>> depending on the machine for which one generates code. This may
>> become important in the future as machines have more processors
>> (cores) and/or less memory per node. With hand-written code these
>> optimisations need to be applied manually, while a code-generation
>> system can generate the corresponding optimisations automatically.
>>
>> If one wanted e.g. to use or to experiment with multi-threading or
>> OpenMP, which can potentially save a significant amount of memory,
>> one would have to change only a few lines of Kranc to generate the
>> corresponding directives. This will allow much faster experiments
>> than manually annotating all existing loops in a production code,
>> probably protected by #ifdef statements to be able to switch forth
>> and back.
>>
>> -erik
>>
>> --
>> Erik Schnetter
>>
>> My email is as private as my paper mail. I therefore support
>> encrypting
>> and signing email messages. Get my PGP key from www.keyserver.net.
>>
>>
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: PGP.sig
>> Type: application/pgp-signature
>> Size: 186 bytes
>> Desc: This is a digitally signed message part
>> Url :
>>
> http://www.cactuscode.org/pipermail/developers/attachments/20070704/
> b2914631/attachment-0001.bin
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Wed, 04 Jul 2007 10:31:20 +0200
>> From: Denis Pollney
>> Subject: Re: [Developers] ADMMacros, syntax errors in C version
>> To: developers at cactuscode.org
>> Message-ID: <1183537880.30972.36.camel at x41>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> On Wed, 2007-07-04 at 10:16 +0200, Erik Schnetter wrote:
>>> On Jul 4, 2007, at 09:48:31, Frank L?ffler wrote:
>>>
>>>> Hi,
>>>>
>>>> this patch fixes two missing ";" in the C version.
>>>
>>> Frank,
>>>
>>> thanks for the correction. I have applied your patch.
>>>
>>> The fact that this code did not compile before indicates that the C
>>> version of the macros has not yet been thoroughly tested. You
>>> should
>>> be very careful if you want to use it. Historically, only the
>>> Fortran version has of ADMMacros been used.
>>
>> There are a couple of places where the C versions of the macros are
>> simply wrong. I have the impression that at some point in the very
>> early history of the code, when they were experimenting with things
>> like how to finite difference the advection terms and how the
>> constraints are added into the BSSN, they stopped maintaining both
>> versions of the macros simultaneously.
>>
>> If you really need C macros, I agree with Erik that it's probably
>> easier to start from scratch than to go through each macro and
>> check that the C and Fortran versions are compatible.
>>
>> Denis.
>>
>> --
>> ---------------------------------------------------------------------
>> -
>> Denis Pollney office:
>> +49-331-567-7623
>> Max-Planck-Institut fuer Gravitationsphysik mobile:
>> +49-170-302-3132
>> Albert-Einstein-Institut, Am Muehlenberg 1, D-14476, Golm, Germany
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: not available
>> Type: application/pgp-signature
>> Size: 189 bytes
>> Desc: This is a digitally signed message part
>> Url :
>>
> http://www.cactuscode.org/pipermail/developers/attachments/20070704/
> f6a97ccc/attachment-0001.bin
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Wed, 4 Jul 2007 11:15:25 +0200
>> From: Frank L?ffler
>> Subject: Re: [Developers] ADMMacros, syntax errors in C version
>> To: developers at cactuscode.org
>> Message-ID: <20070704091524.GP12161 at peterpan.ap.op.sissa.it>
>> Content-Type: text/plain; charset=utf-8
>>
>> On Wed, Jul 04, 2007 at 10:31:20AM +0200, Denis Pollney wrote:
>>> There are a couple of places where the C versions of the macros are
>>> simply wrong.
>>
>> I know that those errors mean that nobody used them at all yet. I
>> would
>> only use them to debug some things, but maybe I am really better
>> off by
>> using Fortran code for that.
>> On the other hand, _some_ of the macros are used, also by C code.
>>
>> What can we do to improve the situation? We could
>> a) remove the code, which is wrong
>> b) correct the wrong code
>> c) rething the whole Macros
>>
>> c) might be the best for the long term, but for a) and b) we have to
>> identify the wrong code first. Can you point at some places?
>>
>> Frank
>>
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Wed, 4 Jul 2007 11:42:49 +0200
>> From: Erik Schnetter
>> Subject: Re: [Developers] ADMMacros, syntax errors in C version
>> To: developers at cactuscode.org
>> Message-ID: <7A2B2288-DB6F-4487-AA82-F002D1647247 at cct.lsu.edu>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> On Jul 4, 2007, at 11:15:25, Frank L?ffler wrote:
>>
>>> On Wed, Jul 04, 2007 at 10:31:20AM +0200, Denis Pollney wrote:
>>>> There are a couple of places where the C versions of the macros are
>>>> simply wrong.
>>>
>>> I know that those errors mean that nobody used them at all yet. I
>>> would
>>> only use them to debug some things, but maybe I am really better
>>> off by
>>> using Fortran code for that.
>>> On the other hand, _some_ of the macros are used, also by C code.
>>
>> Where is that? That is, which C thorn uses these macros?
>>
>> -erik
>>
>> --
>> Erik Schnetter
>>
>> My email is as private as my paper mail. I therefore support
>> encrypting
>> and signing email messages. Get my PGP key from www.keyserver.net.
>>
>>
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: PGP.sig
>> Type: application/pgp-signature
>> Size: 186 bytes
>> Desc: This is a digitally signed message part
>> Url :
>>
> http://www.cactuscode.org/pipermail/developers/attachments/
> 20070704/29329a16/attachment-0001.bin
>>
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Wed, 4 Jul 2007 11:56:28 +0200
>> From: Frank L?ffler
>> Subject: Re: [Developers] ADMMacros, syntax errors in C version
>> To: developers at cactuscode.org
>> Message-ID: <20070704095628.GU12161 at peterpan.ap.op.sissa.it>
>> Content-Type: text/plain; charset=utf-8
>>
>> On Wed, Jul 04, 2007 at 11:42:49AM +0200, Erik Schnetter wrote:
>>> Where is that? That is, which C thorn uses these macros?
>>
>> at least:
>>
>> AEIDevelopment/ADMMass
>> CactusEinstein/ADMAnalysis
>> Whisky_Dev/Whisky_SSIVP
>>
>> Frank
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Developers mailing list
>> Developers at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/developers
>>
>>
>> End of Developers Digest, Vol 45, Issue 1
>> *****************************************
>>
>
>
>
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>
--
Erik Schnetter
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from www.keyserver.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070708/a1b1f606/attachment.bin
From sebastiano.bernuzzi at gmail.com Thu Jul 12 04:39:34 2007
From: sebastiano.bernuzzi at gmail.com (sebastiano bernuzzi)
Date: Thu, 12 Jul 2007 11:39:34 +0200
Subject: [Developers] portland compiler and ADMConstraints runtime error
Message-ID: <793f07c70707120239h3fbee7d9wd444d3fabce2fd21@mail.gmail.com>
dear all
I'm trying to compile a standard cactus-carpet-whisky (dev) configuration
cheked out recently,
with these options:
F77=pgf77
F90=pgf90
F90FLAGS=-Mx,125,0x200 -Mextend
F77FLAGS=-Mx,125,0x200 -Mextend
it compiles but I obtain this runtime error:
s', 'WHISKY::rho', 'ADMCONSTRAINTS::momz', 'ADMCONSTRAINTS::momy',
'ADMCONSTRAINTS::momx', 'ADMCONSTRAINTS::ham', 'ADMBASE::betaz',
'ADMBASE::betay', 'ADMBASE::betax', 'ADMBASE::alp', 'ADMBASE::gzz',
'ADMBASE::gyz', 'ADMBASE::gyy', 'ADMBASE::gxz', 'ADMBASE::gxy',
'ADMBASE::gxx'
INFO (CarpetIOASCII): I/O Method 'IOASCII_2D' registered: 2D AMR output of
grid variables to ASCII files
INFO (CarpetIOASCII): I/O Method 'IOASCII_3D' registered: 3D AMR output of
grid variables to ASCII files
INFO (WaveExtractGeneral): setup GH
INFO (WaveExtractGeneral): Output directory is './StarDAT/'
INFO (WaveExtractGeneral): Setting out_every to 1
WARNING[L1,P0] (CartGrid3D): Unknown variable
'admconstraints::hamnormalize
d' in SetCartSymVN
WARNING level 0 in thorn ADMConstraints processor 0 host
master.albert2n.pr.infn.it
(line 53 of InitSymBound.F):
-> Error set
ting symmetries for ADMConstraints::hamnormalized
WARNING level 0 in thorn ADMConstraints processor 0 host
master.albert2n.pr.infn.it
(line 53 of InitSymBound.F):
-> Error set
ting symmetries for ADMConstraints::hamnormalized
does someone know why?
thank you
--
Sebastiano Bernuzzi
SKYPE: sebastiano.bernuzzi
------------------------------------------------------
www.fis.unipr.it/~bernuzzi
www.mojoshouse.net
------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cactuscode.org/pipermail/developers/attachments/20070712/6e588f6e/attachment-0001.html
From baiotti at aei.mpg.de Fri Jul 20 03:31:03 2007
From: baiotti at aei.mpg.de (Luca Baiotti)
Date: Fri, 20 Jul 2007 10:31:03 +0200 (CEST)
Subject: [Developers] Steerable parameter of AHFinder (Erik)
Message-ID: <3242467.1184920263823.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
Hi,
I have steered the parameters AHFinderDirect::find_after_individual[n]
at recovery (to an earlier time, so that at the recovery time it should
havfe already searched for the horizon) and this caused a crash in
AHFinder. Does anyone have experience with this?
The stderr/out says:
INFO (AHFinderDirect): proc 0: searching for horizon 1/3
cactus_belladonna_NoDebug_allThorns:
/data1/baiotti/Cactus/configs/belladonna_NoDebug_allT
horns/build/AHFinderDirect/patch/coords.cc:313: Assertion
`jtutil::fuzzy::NE(r, 0.0)'
failed.
Abort (core dumped)
The backtrace says:
#0 0x00002aaaab69143a in raise () from /lib64/tls/libc.so.6
#1 0x00002aaaab692870 in abort () from /lib64/tls/libc.so.6
#2 0x00002aaaab68aaeb in __assert_fail () from /lib64/tls/libc.so.6
#3 0x000000000124a2b8 in
partial_xyz_wrt_r_mu_nu__Q2_14AHFinderDirect12local_coordsFdN21RdN84 ()
#4 0x000000000121f05a in
partial_xyz_wrt_r_rho_sigma__Q2_14AHFinderDirect7z_patchCFdN21RdN84 ()
#5 0x000000000121c57b in
rho_sigma_metric__Q2_14AHFinderDirect5patchCFdN91T1RdRdRd ()
#6 0x000000000121d355 in
__CPR94__integrate_gridfn__Q2_14AHFinderDirect5patchCFiN71Q3_J21JJ37J18integration_method
()
#7 0x000000000122c42e in
__CPR106__integrate_gridfn__Q2_14AHFinderDirect12patch_systemCFibN22N71Q3_J21J5patch18integration_method
()
#8 0x000000000120cad6 in
__CPR435__Newton__14AHFinderDirectFPC4_cGHiN22RQ2_J8J16horizon_sequencePCPQ2_J8J7AH_dataRCQ2_J8J16cactus_grid_infoRCQ2_J8J13geometry_infoRCQ2_J8J13JJacobian_infoRCQ2_J8J11solver_infoRCQ2_J8J7IO_infoRCQ2_J8J19BH_diagnostics_infobRCQ2_J8J10error_infoRCQ2_J8J12verbose_infoRQ2_J8J24iteration_status_buffers
()
#9 0x00000000012089fa in AHFinderDirect_find_horizons ()
#10 0x0000000000409345 in CCTK_CallFunction ()
#11 0x000000000134edb9 in Carpet::CallFunction ()
#12 0x000000000040b4e0 in CCTKi_ScheduleCallFunction ()
#13 0x000000000040e1b1 in ScheduleTraverseFunction ()
#14 0x000000000040df9b in ScheduleTraverseGroup ()
#15 0x000000000040ddf2 in CCTKi_DoScheduleTraverse ()
#16 0x000000000040a328 in ScheduleTraverse ()
#17 0x0000000000409aa6 in CCTK_ScheduleTraverse ()
#18 0x00000000012f3daa in Carpet::ScheduleTraverse ()
#19 0x00000000012f0f9e in Carpet::CallPostRecoverVariables ()
#20 0x00000000012f08ba in Carpet::Initialise ()
#21 0x000000000040566b in main ()
From yosef at astro.rit.edu Fri Jul 20 06:00:08 2007
From: yosef at astro.rit.edu (Yosef Zlochower)
Date: Fri, 20 Jul 2007 07:00:08 -0400
Subject: [Developers] Steerable parameter of AHFinder (Erik)
In-Reply-To: <3242467.1184920263823.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
References: <3242467.1184920263823.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
Message-ID: <46A095B8.1010404@astro.rit.edu>
Hi,
I see this behavior with the 'Erik' tagged version of AHFinderDirect.
Apparently,
at least for some architectures, if horizon n was never found, then on
recovery,
the grid function ah_radius[n] will be filled with zeros. It is these
zeros that trigger
the abort (although I don't understand why they are ever used ... ).
As a workaround what I do is modify the function
void BH_diagnostics::load(CCTK_ARGUMENTS, const int horizon_number) in
AHFinderDirect/src/driver/BH_diagnostics.cc
so that it changes a radius of zero to a non-zero value.
Yosef
Luca Baiotti wrote:
> Hi,
>
> I have steered the parameters AHFinderDirect::find_after_individual[n]
> at recovery (to an earlier time, so that at the recovery time it should
> havfe already searched for the horizon) and this caused a crash in
> AHFinder. Does anyone have experience with this?
>
> The stderr/out says:
>
> INFO (AHFinderDirect): proc 0: searching for horizon 1/3
> cactus_belladonna_NoDebug_allThorns:
> /data1/baiotti/Cactus/configs/belladonna_NoDebug_allT
> horns/build/AHFinderDirect/patch/coords.cc:313: Assertion
> `jtutil::fuzzy::NE(r, 0.0)'
> failed.
> Abort (core dumped)
>
>
>
>
>
> The backtrace says:
>
> #0 0x00002aaaab69143a in raise () from /lib64/tls/libc.so.6
> #1 0x00002aaaab692870 in abort () from /lib64/tls/libc.so.6
> #2 0x00002aaaab68aaeb in __assert_fail () from /lib64/tls/libc.so.6
> #3 0x000000000124a2b8 in
> partial_xyz_wrt_r_mu_nu__Q2_14AHFinderDirect12local_coordsFdN21RdN84 ()
> #4 0x000000000121f05a in
> partial_xyz_wrt_r_rho_sigma__Q2_14AHFinderDirect7z_patchCFdN21RdN84 ()
> #5 0x000000000121c57b in
> rho_sigma_metric__Q2_14AHFinderDirect5patchCFdN91T1RdRdRd ()
> #6 0x000000000121d355 in
>
> __CPR94__integrate_gridfn__Q2_14AHFinderDirect5patchCFiN71Q3_J21JJ37J18integration_method
> ()
> #7 0x000000000122c42e in
>
> __CPR106__integrate_gridfn__Q2_14AHFinderDirect12patch_systemCFibN22N71Q3_J21J5patch18integration_method
> ()
> #8 0x000000000120cad6 in
>
> __CPR435__Newton__14AHFinderDirectFPC4_cGHiN22RQ2_J8J16horizon_sequencePCPQ2_J8J7AH_dataRCQ2_J8J16cactus_grid_infoRCQ2_J8J13geometry_infoRCQ2_J8J13JJacobian_infoRCQ2_J8J11solver_infoRCQ2_J8J7IO_infoRCQ2_J8J19BH_diagnostics_infobRCQ2_J8J10error_infoRCQ2_J8J12verbose_infoRQ2_J8J24iteration_status_buffers
> ()
> #9 0x00000000012089fa in AHFinderDirect_find_horizons ()
> #10 0x0000000000409345 in CCTK_CallFunction ()
> #11 0x000000000134edb9 in Carpet::CallFunction ()
> #12 0x000000000040b4e0 in CCTKi_ScheduleCallFunction ()
> #13 0x000000000040e1b1 in ScheduleTraverseFunction ()
> #14 0x000000000040df9b in ScheduleTraverseGroup ()
> #15 0x000000000040ddf2 in CCTKi_DoScheduleTraverse ()
> #16 0x000000000040a328 in ScheduleTraverse ()
> #17 0x0000000000409aa6 in CCTK_ScheduleTraverse ()
> #18 0x00000000012f3daa in Carpet::ScheduleTraverse ()
> #19 0x00000000012f0f9e in Carpet::CallPostRecoverVariables ()
> #20 0x00000000012f08ba in Carpet::Initialise ()
> #21 0x000000000040566b in main ()
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>
From schnetter at cct.lsu.edu Fri Jul 20 09:47:50 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Fri, 20 Jul 2007 10:47:50 -0400
Subject: [Developers] Steerable parameter of AHFinder (Erik)
In-Reply-To: <3242467.1184920263823.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
References: <3242467.1184920263823.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
Message-ID: <98DC7D31-8B8A-493C-93D1-3D94338109AC@cct.lsu.edu>
On Jul 20, 2007, at 04:31:03, Luca Baiotti wrote:
> Hi,
>
> I have steered the parameters AHFinderDirect::find_after_individual[n]
> at recovery (to an earlier time, so that at the recovery time it
> should
> havfe already searched for the horizon) and this caused a crash in
> AHFinder. Does anyone have experience with this?
>
> The stderr/out says:
>
> INFO (AHFinderDirect): proc 0: searching for horizon 1/3
> cactus_belladonna_NoDebug_allThorns:
> /data1/baiotti/Cactus/configs/belladonna_NoDebug_allT
> horns/build/AHFinderDirect/patch/coords.cc:313: Assertion
> `jtutil::fuzzy::NE(r, 0.0)'
> failed.
> Abort (core dumped)
Hi Luca,
I think that this problem has been corrected in the latest version in
CVS. Do you have version 1.43.2.3 of the file coords.cc?
-erik
--
Erik Schnetter
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from www.keyserver.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070720/414fbcb1/attachment.bin
From baiotti at aei.mpg.de Sun Jul 22 02:08:41 2007
From: baiotti at aei.mpg.de (Luca Baiotti)
Date: Sun, 22 Jul 2007 09:08:41 +0200 (CEST)
Subject: [Developers] Steerable parameter of AHFinder (Erik)
In-Reply-To: <98DC7D31-8B8A-493C-93D1-3D94338109AC@cct.lsu.edu>
References: <3242467.1184920263823.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
<98DC7D31-8B8A-493C-93D1-3D94338109AC@cct.lsu.edu>
Message-ID: <5812470.1185088121780.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
On Jul 20, 2007 04:47 PM, Erik Schnetter wrote:
> On Jul 20, 2007, at 04:31:03, Luca Baiotti wrote:
>
> > Hi,
> >
> > I have steered the parameters
> > AHFinderDirect::find_after_individual[n]
> > at recovery (to an earlier time, so that at the recovery time it
> > should
> > havfe already searched for the horizon) and this caused a crash in
> > AHFinder. Does anyone have experience with this?
> >
> > The stderr/out says:
> >
> > INFO (AHFinderDirect): proc 0: searching for horizon 1/3
> > cactus_belladonna_NoDebug_allThorns:
> > /data1/baiotti/Cactus/configs/belladonna_NoDebug_allT
> > horns/build/AHFinderDirect/patch/coords.cc:313: Assertion
> > `jtutil::fuzzy::NE(r, 0.0)'
> > failed.
> > Abort (core dumped)
>
> Hi Luca,
>
> I think that this problem has been corrected in the latest version in
> CVS. Do you have version 1.43.2.3 of the file coords.cc?
Yes I had it.
Luca
From schnetter at cct.lsu.edu Sun Jul 22 23:29:06 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 23 Jul 2007 13:29:06 +0900
Subject: [Developers] Steerable parameter of AHFinder (Erik)
In-Reply-To: <5812470.1185088121780.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
References: <3242467.1184920263823.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
<98DC7D31-8B8A-493C-93D1-3D94338109AC@cct.lsu.edu>
<5812470.1185088121780.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
Message-ID: <9EC6CC5C-6B36-412B-BEB4-733201A7946C@cct.lsu.edu>
On Jul 22, 2007, at 16:08:41, Luca Baiotti wrote:
> On Jul 20, 2007 04:47 PM, Erik Schnetter
> wrote:
>
>> On Jul 20, 2007, at 04:31:03, Luca Baiotti wrote:
>>
>>> Hi,
>>>
>>> I have steered the parameters
>>> AHFinderDirect::find_after_individual[n]
>>> at recovery (to an earlier time, so that at the recovery time it
>>> should
>>> havfe already searched for the horizon) and this caused a crash in
>>> AHFinder. Does anyone have experience with this?
>>>
>>> The stderr/out says:
>>>
>>> INFO (AHFinderDirect): proc 0: searching for horizon 1/3
>>> cactus_belladonna_NoDebug_allThorns:
>>> /data1/baiotti/Cactus/configs/belladonna_NoDebug_allT
>>> horns/build/AHFinderDirect/patch/coords.cc:313: Assertion
>>> `jtutil::fuzzy::NE(r, 0.0)'
>>> failed.
>>> Abort (core dumped)
>>
>> Hi Luca,
>>
>> I think that this problem has been corrected in the latest version in
>> CVS. Do you have version 1.43.2.3 of the file coords.cc?
>
> Yes I had it.
This version does not have an assert statement in line 313; it is
commented out. Did you rebuild the executable? You can use
Formaline to check the source which you compiled.
-erik
--
Erik Schnetter
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from www.keyserver.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070723/93ad685a/attachment.bin
From bgiacoma at aei.mpg.de Mon Jul 23 03:26:46 2007
From: bgiacoma at aei.mpg.de (Bruno Giacomazzo)
Date: Mon, 23 Jul 2007 10:26:46 +0200 (CEST)
Subject: [Developers] problems compiling cactus on mac osx with ifort
Message-ID:
Hi,
I have some problems compiling Cactus with the Intel
fortran compiler on a MacBookPro with Mac OS X version 10.4.9.
I'm using the Intel fortran compiler version 10.0, gcc 4.0.1 and mpich2
version 1.0.5
First of all I had a problem during the configuration since mpich2
doesn't install tarch. So I have applied a patch that Steve sent one year
ago to the cactus user ml (I have attached it) and it worked.
But I have still problem. At the end I get the following error:
Creating cactus_Whisky_carpet in /Users/bgiacoma/Cactus/exe from [...]
i686-apple-darwin8-g++-4.0.1: /opt/intel/fc/10.0.016/lib/icrt.link: No
such file or directory
i686-apple-darwin8-g++-4.0.1: unrecognized option '-Qy'
make[1]: *** [/Users/bgiacoma/Cactus/exe/cactus_Whisky_carpet] Error 1
make: *** [Whisky_carpet] Error 2
Googling for it I found that somebody else had the same problem but I was
not able to get the solution for it. Any suggestion? I'm using the
development version of Cactus. The config file I have used is attached.
Thank you,
Bruno
--
Dr. Bruno Giacomazzo
Max Planck Institute for Gravitational Physics
Albert Einstein Institute
Am Muehlenberg 1
D-14476 Potsdam
Germany
Tel. : +49 331 567 7183
Fax : +49 331 567 7252
cell. : +49 173 826 4488
email : bgiacoma at aei.mpg.de
-------------------------------------------------
There are only 10 types of people in the world:
Those who understand binary, and those who don't
-------------------------------------------------
-------------- next part --------------
Index: lib/make/extras/MPI/MPICH
===================================================================
RCS file: /cactusdevcvs/Cactus/lib/make/extras/MPI/MPICH,v
retrieving revision 1.25
diff -u -r1.25 MPICH
--- lib/make/extras/MPI/MPICH 24 Oct 2005 09:12:21 -0000 1.25
+++ lib/make/extras/MPI/MPICH 21 Apr 2006 09:57:16 -0000
@@ -43,15 +43,23 @@
# Find the MPICH architecture
if test -z "$MPICH_ARCH" ; then
- if test -x "$MPICH_DIR/bin/tarch" ; then
- MPICH_ARCH=`$MPICH_DIR/bin/tarch`
- echo " MPICH architecture is $MPICH_ARCH"
- else
- echo " Cannot execute $MPICH_DIR/bin/tarch"
- exit 2
+ # MPICH2 doesn't install tarch
+ if test ! -x "$MPICH_DIR/bin/mpich2version" ; then
+ if test -x "$MPICH_DIR/bin/tarch" ; then
+ MPICH_ARCH=`$MPICH_DIR/bin/tarch`
+ echo " MPICH architecture is $MPICH_ARCH"
+ else
+ echo " Cannot execute $MPICH_DIR/bin/tarch"
+ exit 2
+ fi
fi
fi
+if test -x "$MPICH_DIR/bin/mpich2version" ; then
+ # see MPICH2 User's Guide, sect. 5.3: Special Issues for C++
+ CXXFLAGS="$CXXFLAGS -DMPICH_IGNORE_CXX_SEEK"
+fi
+
# Find the MPICH device - this isn't necessary for mpich-1.2.0
if test -d "$MPICH_DIR/build/$MPICH_ARCH" ; then
@@ -176,7 +184,13 @@
fi
# Set the MPI version name
-MPI_VERSION="MPICH_$MPICH_DEVICE"
+if test -x "$MPICH_DIR/bin/mpich2version" ; then
+ MPICH2_VERSION=`mpich2version -v`
+ MPICH2_DEVICE=`mpich2version -d`
+ MPI_VERSION="MPICH2 ${MPICH2_VERSION} (${MPICH2_DEVICE})"
+else
+ MPI_VERSION="MPICH_$MPICH_DEVICE"
+fi
# Finally set the library lines.
MPI_LIBS="$MPICH_LIB $MPICH_DEVICE_LIBS"
------------------------------------------------------------------------
* Previous message: [Users] trouble building cactus <001800.html>
* Next message: [Users] problem with CactusEinstein/ADMConstraints
and AEIThorns/Exact <001801.html>
* *Messages sorted by:* [ date ] [ thread ]
[ subject ] [ author ]
------------------------------------------------------------------------
More information about the Users mailing list
-------------- next part --------------
# CONFIGURATION : Whisky_carpet
# CONFIG-DATE : Sun Jul 22 17:53:26 2007 (GMT)
# CONFIG-HOST : mac20.local
# CONFIG-STATUS : 0
# CONFIG-OPTIONS :
BLAS_DIR=/usr/lib
CFLAGS=-Drestrict= -std=c99 -DMPICH_IGNORE_CXX_SEEK
CPPFLAGS=-DMPICH_IGNORE_CXX_SEEK
CXXFLAGS=-DMPICH_IGNORE_CXX_SEEK
F77=ifort
F90=ifort
FPP=${PERL} ${CCTK_HOME}/lib/sbin/cpp.pl
GSL_DIR=/sw/lib
HDF5=yes
HDF5_DIR=/usr/local
LAPACK=yes
LAPACK_DIR=/Library/Frameworks/Intel_MKL.framework/Versions/Current/lib/32
MPI=MPICH
MPICH_DIR=/usr/local
PERL=perl
THORNLIST=Whisky_carpet.th
THORNLIST_DIR=thornlists
From bgiacoma at aei.mpg.de Mon Jul 23 03:50:45 2007
From: bgiacoma at aei.mpg.de (Bruno Giacomazzo)
Date: Mon, 23 Jul 2007 10:50:45 +0200 (CEST)
Subject: [Developers] [Users] problems compiling cactus on mac osx with
ifort
In-Reply-To:
References:
Message-ID:
Nils,
On Mon, 23 Jul 2007, Nils Dorband wrote:
> I don't know what the problem you see is, but I am sending you the
> configuration that I am successfully using with os x (it is a bit messy and
> some options are taken from Erik, so I am not sure to what extend they are
> needed). It is using the gnu fortran compiler with lam mpi. I did not try
> intel yet, simply because gnu was working fine for me.
I will try your configuration. I'm using Intel since gfortran
cannot compile some other fortran90 codes I have.
Cheers,
Bruno
--
Dr. Bruno Giacomazzo
Max Planck Institute for Gravitational Physics
Albert Einstein Institute
Am Muehlenberg 1
D-14476 Potsdam
Germany
Tel. : +49 331 567 7183
Fax : +49 331 567 7252
cell. : +49 173 826 4488
email : bgiacoma at aei.mpg.de
-------------------------------------------------
There are only 10 types of people in the world:
Those who understand binary, and those who don't
-------------------------------------------------
From baiotti at aei.mpg.de Thu Jul 26 06:38:58 2007
From: baiotti at aei.mpg.de (Luca Baiotti)
Date: Thu, 26 Jul 2007 13:38:58 +0200
Subject: [Developers] Steerable parameter of AHFinder (Erik)
In-Reply-To: <9EC6CC5C-6B36-412B-BEB4-733201A7946C@cct.lsu.edu>
References: <3242467.1184920263823.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de> <98DC7D31-8B8A-493C-93D1-3D94338109AC@cct.lsu.edu> <5812470.1185088121780.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
<9EC6CC5C-6B36-412B-BEB4-733201A7946C@cct.lsu.edu>
Message-ID: <46A887D2.2030100@aei.mpg.de>
Erik Schnetter wrote:
> On Jul 22, 2007, at 16:08:41, Luca Baiotti wrote:
>
>> On Jul 20, 2007 04:47 PM, Erik Schnetter wrote:
>>
>>> On Jul 20, 2007, at 04:31:03, Luca Baiotti wrote:
>>>
>>>> Hi,
>>>>
>>>> I have steered the parameters
>>>> AHFinderDirect::find_after_individual[n]
>>>> at recovery (to an earlier time, so that at the recovery time it
>>>> should
>>>> havfe already searched for the horizon) and this caused a crash in
>>>> AHFinder. Does anyone have experience with this?
>>>>
>>>> The stderr/out says:
>>>>
>>>> INFO (AHFinderDirect): proc 0: searching for horizon 1/3
>>>> cactus_belladonna_NoDebug_allThorns:
>>>> /data1/baiotti/Cactus/configs/belladonna_NoDebug_allT
>>>> horns/build/AHFinderDirect/patch/coords.cc:313: Assertion
>>>> `jtutil::fuzzy::NE(r, 0.0)'
>>>> failed.
>>>> Abort (core dumped)
>>>
>>> Hi Luca,
>>>
>>> I think that this problem has been corrected in the latest version in
>>> CVS. Do you have version 1.43.2.3 of the file coords.cc?
>>
>> Yes I had it.
>
> This version does not have an assert statement in line 313; it is
> commented out. Did you rebuild the executable? You can use Formaline
> to check the source which you compiled.
Hi Erik,
I have checked with formaline that I really have the version 1.43.2.3
and its line 313 reads:
assert( jtutil::fuzzy::NE(r, 0.0) );
So the problem is still there.
Luca.
From schnetter at cct.lsu.edu Sat Jul 28 00:54:01 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 28 Jul 2007 14:54:01 +0900
Subject: [Developers] Steerable parameter of AHFinder (Erik)
In-Reply-To: <46A887D2.2030100@aei.mpg.de>
References: <3242467.1184920263823.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de> <98DC7D31-8B8A-493C-93D1-3D94338109AC@cct.lsu.edu> <5812470.1185088121780.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
<9EC6CC5C-6B36-412B-BEB4-733201A7946C@cct.lsu.edu>
<46A887D2.2030100@aei.mpg.de>
Message-ID: <5641C7F5-0FCC-421E-833D-7FDA16C5EF1D@cct.lsu.edu>
On Jul 26, 2007, at 20:38:58, Luca Baiotti wrote:
> I have checked with formaline that I really have the version 1.43.2.3
> and its line 313 reads:
>
> assert( jtutil::fuzzy::NE(r, 0.0) );
>
>
> So the problem is still there.
I have checked again, and you are right. This file has several such
assert statements, and the one I was looking at was in line 399.
Sorry for the confusion.
I have committed the commenting-out of the other assert statements as
well.
-erik
--
Erik Schnetter
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from www.keyserver.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070728/30de1997/attachment.bin
From schnetter at cct.lsu.edu Mon Jul 30 19:34:22 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 30 Jul 2007 19:34:22 -0500
Subject: [Developers] Steerable parameter of AHFinder (Erik)
In-Reply-To: <46A095B8.1010404@astro.rit.edu>
References: <3242467.1184920263823.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de>
<46A095B8.1010404@astro.rit.edu>
Message-ID: <2DB923A4-BFE4-4AE0-9B1B-4D1E442641CA@cct.lsu.edu>
Yes, this is correct. The corresponding change to correct this
(faulty) behaviour requires storing a flag describing whether a
horizon has been found at some previous time. This information is
also interesting for users of the horizon finder, and therefore
SphericalSurface should also be updated. We plan to do that in the
near future, after some careful testing.
In the mean time I have disable the assert statements, so that this
error should not lead to an abort any more.
-erik
On Jul 20, 2007, at 06:00:08, Yosef Zlochower wrote:
> Hi,
>
> I see this behavior with the 'Erik' tagged version of
> AHFinderDirect.
> Apparently,
> at least for some architectures, if horizon n was never found, then on
> recovery,
> the grid function ah_radius[n] will be filled with zeros. It is these
> zeros that trigger
> the abort (although I don't understand why they are ever used ... ).
> As a workaround what I do is modify the function
> void BH_diagnostics::load(CCTK_ARGUMENTS, const int
> horizon_number) in
> AHFinderDirect/src/driver/BH_diagnostics.cc
> so that it changes a radius of zero to a non-zero value.
>
> Yosef
>
> Luca Baiotti wrote:
>> Hi,
>>
>> I have steered the parameters AHFinderDirect::find_after_individual
>> [n]
>> at recovery (to an earlier time, so that at the recovery time it
>> should
>> havfe already searched for the horizon) and this caused a crash in
>> AHFinder. Does anyone have experience with this?
>>
>> The stderr/out says:
>>
>> INFO (AHFinderDirect): proc 0: searching for horizon 1/3
>> cactus_belladonna_NoDebug_allThorns:
>> /data1/baiotti/Cactus/configs/belladonna_NoDebug_allT
>> horns/build/AHFinderDirect/patch/coords.cc:313: Assertion
>> `jtutil::fuzzy::NE(r, 0.0)'
>> failed.
>> Abort (core dumped)
>>
>>
>>
>>
>>
>> The backtrace says:
>>
>> #0 0x00002aaaab69143a in raise () from /lib64/tls/libc.so.6
>> #1 0x00002aaaab692870 in abort () from /lib64/tls/libc.so.6
>> #2 0x00002aaaab68aaeb in __assert_fail () from /lib64/tls/libc.so.6
>> #3 0x000000000124a2b8 in
>> partial_xyz_wrt_r_mu_nu__Q2_14AHFinderDirect12local_coordsFdN21RdN84
>> ()
>> #4 0x000000000121f05a in
>> partial_xyz_wrt_r_rho_sigma__Q2_14AHFinderDirect7z_patchCFdN21RdN84 (
>> )
>> #5 0x000000000121c57b in
>> rho_sigma_metric__Q2_14AHFinderDirect5patchCFdN91T1RdRdRd ()
>> #6 0x000000000121d355 in
>>
>> __CPR94__integrate_gridfn__Q2_14AHFinderDirect5patchCFiN71Q3_J21JJ37J
>> 18integration_method
>> ()
>> #7 0x000000000122c42e in
>>
>> __CPR106__integrate_gridfn__Q2_14AHFinderDirect12patch_systemCFibN22N
>> 71Q3_J21J5patch18integration_method
>> ()
>> #8 0x000000000120cad6 in
>>
>> __CPR435__Newton__14AHFinderDirectFPC4_cGHiN22RQ2_J8J16horizon_sequen
>> cePCPQ2_J8J7AH_dataRCQ2_J8J16cactus_grid_infoRCQ2_J8J13geometry_infoR
>> CQ2_J8J13JJacobian_infoRCQ2_J8J11solver_infoRCQ2_J8J7IO_infoRCQ2_J8J1
>> 9BH_diagnostics_infobRCQ2_J8J10error_infoRCQ2_J8J12verbose_infoRQ2_J8
>> J24iteration_status_buffers
>> ()
>> #9 0x00000000012089fa in AHFinderDirect_find_horizons ()
>> #10 0x0000000000409345 in CCTK_CallFunction ()
>> #11 0x000000000134edb9 in Carpet::CallFunction ()
>> #12 0x000000000040b4e0 in CCTKi_ScheduleCallFunction ()
>> #13 0x000000000040e1b1 in ScheduleTraverseFunction ()
>> #14 0x000000000040df9b in ScheduleTraverseGroup ()
>> #15 0x000000000040ddf2 in CCTKi_DoScheduleTraverse ()
>> #16 0x000000000040a328 in ScheduleTraverse ()
>> #17 0x0000000000409aa6 in CCTK_ScheduleTraverse ()
>> #18 0x00000000012f3daa in Carpet::ScheduleTraverse ()
>> #19 0x00000000012f0f9e in Carpet::CallPostRecoverVariables ()
>> #20 0x00000000012f08ba in Carpet::Initialise ()
>> #21 0x000000000040566b in main ()
>>
>> _______________________________________________
>> Developers mailing list
>> Developers at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/developers
>>
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>
--
Erik Schnetter
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from www.keyserver.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070730/cca261b9/attachment.bin