From oweidner at cct.lsu.edu  Mon Dec  3 14:24:36 2007
From: oweidner at cct.lsu.edu (Ole Weidner)
Date: Mon, 3 Dec 2007 14:24:36 -0600
Subject: [Users] CactusIO::IOJpeg standard vs. remove mode / output format
Message-ID: <CDCFD32D-8070-46E9-AA95-D3E4968F57D8@cct.lsu.edu>

Aloha,

I'm using the IOJpeg thorn for continuous output slice generation for  
an oceanographic model recently "ported" to cactus. The jpeg files are  
used to create an mpeg4 movie once the simulation is done.
Since I'm also using the HTTPD thorn for monitoring/steering, I'm  
wondering if there's a rationale behind the fact that the IOJpeg thorn  
doesn't generate the single "remove-mode"-style advertised jpeg file  
that is used by the HTTPD thorn to provide a preview for the current  
time-step. I modified my local copy of the IOJpeg (dev) thorn to  
achieve this. Would it be in general interest to have a feature like  
this in the Cactus development CVS?

Another rather minor annoyance (IMHO;-) is the naming of the  
continuous output files: the scheme is varname_2D.it_timestep.jpeg  
which results in something like:

varname_2D.it_1.jpeg
varname_2D.it_2.jpeg
varname_2D.it_3.jpeg
...
varname_2D.it_10.jpeg
...

which makes a lexicographic ordering unnecessary difficult and usually  
(depending on the processing tool - in my case mencoder) requires an  
additional sorting step. Would it make sense to prepend a couple of  
zeros to the format string (Write.c)? Like:

sprintf (filename, "%s%s_%s.it_%08d.jpeg", myGH->out_dir, alias,  
slicename,
             GH->cctk_iteration);

instead of:

sprintf (filename, "%s%s_%s.it_%d.jpeg", myGH->out_dir, alias,  
slicename,
             GH->cctk_iteration);

Cheers,
Ole

From dprideout at gmail.com  Mon Dec  3 14:59:19 2007
From: dprideout at gmail.com (David Rideout)
Date: Mon, 3 Dec 2007 15:59:19 -0500
Subject: [Users] CactusIO::IOJpeg standard vs. remove mode / output
	format
In-Reply-To: <CDCFD32D-8070-46E9-AA95-D3E4968F57D8@cct.lsu.edu>
References: <CDCFD32D-8070-46E9-AA95-D3E4968F57D8@cct.lsu.edu>
Message-ID: <1ce81abb0712031259w140b3beatf5c69ace90522986@mail.gmail.com>

Sounds good.  Why not submit a patch to the patches list?

Cheers,
David

On Dec 3, 2007 3:24 PM, Ole Weidner <oweidner at cct.lsu.edu> wrote:
> Aloha,
>
> I'm using the IOJpeg thorn for continuous output slice generation for
> an oceanographic model recently "ported" to cactus. The jpeg files are
> used to create an mpeg4 movie once the simulation is done.
> Since I'm also using the HTTPD thorn for monitoring/steering, I'm
> wondering if there's a rationale behind the fact that the IOJpeg thorn
> doesn't generate the single "remove-mode"-style advertised jpeg file
> that is used by the HTTPD thorn to provide a preview for the current
> time-step. I modified my local copy of the IOJpeg (dev) thorn to
> achieve this. Would it be in general interest to have a feature like
> this in the Cactus development CVS?
>
> Another rather minor annoyance (IMHO;-) is the naming of the
> continuous output files: the scheme is varname_2D.it_timestep.jpeg
> which results in something like:
>
> varname_2D.it_1.jpeg
> varname_2D.it_2.jpeg
> varname_2D.it_3.jpeg
> ...
> varname_2D.it_10.jpeg
> ...
>
> which makes a lexicographic ordering unnecessary difficult and usually
> (depending on the processing tool - in my case mencoder) requires an
> additional sorting step. Would it make sense to prepend a couple of
> zeros to the format string (Write.c)? Like:
>
> sprintf (filename, "%s%s_%s.it_%08d.jpeg", myGH->out_dir, alias,
> slicename,
>              GH->cctk_iteration);
>
> instead of:
>
> sprintf (filename, "%s%s_%s.it_%d.jpeg", myGH->out_dir, alias,
> slicename,
>              GH->cctk_iteration);
>
> Cheers,
> Ole
> _______________________________________________
> Users mailing list
> Users at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/users
>

From schnetter at cct.lsu.edu  Mon Dec  3 16:46:07 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 3 Dec 2007 16:46:07 -0600
Subject: [Users] CactusIO::IOJpeg standard vs. remove mode / output
	format
In-Reply-To: <CDCFD32D-8070-46E9-AA95-D3E4968F57D8@cct.lsu.edu>
References: <CDCFD32D-8070-46E9-AA95-D3E4968F57D8@cct.lsu.edu>
Message-ID: <E93401B9-36AA-4CBE-9707-8EEFE65B5975@cct.lsu.edu>

On Dec 3, 2007, at 14:24:36, Ole Weidner wrote:

> Aloha,
>
> I'm using the IOJpeg thorn for continuous output slice generation for
> an oceanographic model recently "ported" to cactus. The jpeg files are
> used to create an mpeg4 movie once the simulation is done.
> Since I'm also using the HTTPD thorn for monitoring/steering, I'm
> wondering if there's a rationale behind the fact that the IOJpeg thorn
> doesn't generate the single "remove-mode"-style advertised jpeg file
> that is used by the HTTPD thorn to provide a preview for the current
> time-step. I modified my local copy of the IOJpeg (dev) thorn to
> achieve this. Would it be in general interest to have a feature like
> this in the Cactus development CVS?

Yes, please!

> Another rather minor annoyance (IMHO;-) is the naming of the
> continuous output files: the scheme is varname_2D.it_timestep.jpeg
> which results in something like:
>
> varname_2D.it_1.jpeg
> varname_2D.it_2.jpeg
> varname_2D.it_3.jpeg
> ...
> varname_2D.it_10.jpeg
> ...
>
> which makes a lexicographic ordering unnecessary difficult and usually
> (depending on the processing tool - in my case mencoder) requires an
> additional sorting step. Would it make sense to prepend a couple of
> zeros to the format string (Write.c)? Like:
>
> sprintf (filename, "%s%s_%s.it_%08d.jpeg", myGH->out_dir, alias,
> slicename,
>              GH->cctk_iteration);
>
> instead of:
>
> sprintf (filename, "%s%s_%s.it_%d.jpeg", myGH->out_dir, alias,
> slicename,
>              GH->cctk_iteration);


I would prefer this as well.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>

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/users/attachments/20071203/f81bbfa0/attachment.bin 

From heeilkim at gmail.com  Wed Dec  5 00:03:37 2007
From: heeilkim at gmail.com (Hee Il Kim)
Date: Wed, 5 Dec 2007 15:03:37 +0900
Subject: [Users] non-portable inline problem & c++ void operator declaration
	problem
Message-ID: <c89bf5b50712042203q27ce942cx1c2a1f018e8ba089@mail.gmail.com>

Hi all,

Recently I updated Cactus flesh and failed to make building. The two
relevant messages are attached below. It occured on the ppc64 linux system
using XL compilers. I appreciate your help in advance.

Hee Il


--  1st one ---
"/home/hmlee/Cactus/src/include/cctk_Complex.h", line 109.1: 1506-1108 (I)
The use of keyword '__inline__' is non-portable.
"/usr/include/bits/mathinline.h", line 66.58: 1506-1197 (W) The use of ':'
in designated initializer syntax is non-portable.

--  2nd one ---
Preprocessing
/home/hmlee/Cactus/arrangements/AEIThorns/AHFinderDirect/src/patch
/ghost_zone.cc
Compiling
/home/hmlee/Cactus/arrangements/AEIThorns/AHFinderDirect/src/patch/gho
st_zone.cc
"/home/hmlee/Cactus/configs/rns_pugh/build/AHFinderDirect/patch/ghost_zone.cc",

line 377.8: 1540-0256 (S) A parameter of type "void *" cannot be initialized
wit
h an expression of type "const AHFinderDirect::patch_interp *".
"/home/hmlee/Cactus/configs/rns_pugh/build/AHFinderDirect/patch/ghost_zone.cc",

line 377.8: 1540-1205 (I) The error occurred while converting to parameter 1
of
"operator delete(void *)".
"/usr/include/g++/new", line 96.14: 1540-1298 (I) "extern "C++" void
operator de
lete(void *, void *) throw()" needs to be declared in the containing scope
to be
 found by name lookup.
"/usr/include/g++/new", line 88.6: 1540-1298 (I) "extern "C++" void operator
del
ete(void *, const nothrow_t &) throw()" needs to be declared in the
containing s
cope to be found by name lookup.
1540-1298 (I) "void operator delete(void *, const char *, unsigned long)
throw()
" needs to be declared in the containing scope to be found by name lookup.
"/home/hmlee/Cactus/configs/rns_pugh/build/AHFinderDirect/patch/ghost_zone.cc",

line 377.8: 1540-0256 (S) A parameter of type "void *" cannot be initialized
wit
h an expression of type "const AHFinderDirect::patch_interp *".
"/home/hmlee/Cactus/configs/rns_pugh/build/AHFinderDirect/patch/ghost_zone.cc",

line 377.8: 1540-1205 (I) The error occurred while converting to parameter 1
of
"operator delete(void *)".
"/usr/include/g++/new", line 96.14: 1540-1298 (I) "extern "C++" void
operator de
lete(void *, void *) throw()" needs to be declared in the containing scope
to be
 found by name lookup.
"/usr/include/g++/new", line 88.6: 1540-1298 (I) "extern "C++" void operator
del
ete(void *, const nothrow_t &) throw()" needs to be declared in the
containing s
cope to be found by name lookup.
1540-1298 (I) "void operator delete(void *, const char *, unsigned long)
throw()
" needs to be declared in the containing scope to be found by name lookup.
make[3]: *** [ghost_zone.cc.o] Error 1
make[2]: *** [patch/make.checked] Error 2
make[1]: ***
[/home/hmlee/Cactus/configs/rns_pugh/lib/libthorn_AHFinderDirect.a]
 Error 2
make: *** [rns_pugh] Error 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cactuscode.org/pipermail/users/attachments/20071205/14cd0597/attachment.html 

From tradke at aei.mpg.de  Wed Dec  5 10:46:24 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Wed, 05 Dec 2007 17:46:24 +0100
Subject: [Users] CactusIO::IOJpeg standard vs. remove mode / output
	format
In-Reply-To: <CDCFD32D-8070-46E9-AA95-D3E4968F57D8@cct.lsu.edu>
References: <CDCFD32D-8070-46E9-AA95-D3E4968F57D8@cct.lsu.edu>
Message-ID: <4756D5E0.9040204@aei.mpg.de>

Ole Weidner wrote:
> Aloha,
> 
> I'm using the IOJpeg thorn for continuous output slice generation for  
> an oceanographic model recently "ported" to cactus. The jpeg files are  
> used to create an mpeg4 movie once the simulation is done.
> Since I'm also using the HTTPD thorn for monitoring/steering, I'm  
> wondering if there's a rationale behind the fact that the IOJpeg thorn  
> doesn't generate the single "remove-mode"-style advertised jpeg file  
> that is used by the HTTPD thorn to provide a preview for the current  
> time-step. I modified my local copy of the IOJpeg (dev) thorn to  
> achieve this. Would it be in general interest to have a feature like  
> this in the Cactus development CVS?

If I got this right, you want to have the most recent jpeg image 
advertised when in "standard" mode (currently, nothing is advertised in 
this mode). Sounds like a reasonable suggestion to me.

In the patch you submitted the jpeg is now created twice when in 
"standard" mode. I think it can be rewritten in a more efficient way 
such that  it would generate only one image named after 
'filename_standard_mode' and then, depending on the mode, either rename 
("remove") or copy ("standard") it to 'filename_remove_mode'.

> Another rather minor annoyance (IMHO;-) is the naming of the  
> continuous output files: ...
> which makes a lexicographic ordering unnecessary difficult and usually  
> (depending on the processing tool - in my case mencoder) requires an  
> additional sorting step. Would it make sense to prepend a couple of  
> zeros to the format string (Write.c)? 

That is a good idea !

-- 
Cheers, Thomas.

From oweidner at cct.lsu.edu  Wed Dec  5 15:07:51 2007
From: oweidner at cct.lsu.edu (Ole Weidner)
Date: Wed, 5 Dec 2007 15:07:51 -0600
Subject: [Users] CactusIO::IOJpeg standard vs. remove mode / output
	format
In-Reply-To: <4756D5E0.9040204@aei.mpg.de>
References: <CDCFD32D-8070-46E9-AA95-D3E4968F57D8@cct.lsu.edu>
	<4756D5E0.9040204@aei.mpg.de>
Message-ID: <6E51B300-AB65-40DA-9B06-2D01B320FE8E@cct.lsu.edu>


On Dec 5, 2007, at 10:46 AM, Thomas Radke wrote:

> Ole Weidner wrote:
>> Aloha,
>>
>> I'm using the IOJpeg thorn for continuous output slice generation for
>> an oceanographic model recently "ported" to cactus. The jpeg files  
>> are
>> used to create an mpeg4 movie once the simulation is done.
>> Since I'm also using the HTTPD thorn for monitoring/steering, I'm
>> wondering if there's a rationale behind the fact that the IOJpeg  
>> thorn
>> doesn't generate the single "remove-mode"-style advertised jpeg file
>> that is used by the HTTPD thorn to provide a preview for the current
>> time-step. I modified my local copy of the IOJpeg (dev) thorn to
>> achieve this. Would it be in general interest to have a feature like
>> this in the Cactus development CVS?
>
> If I got this right, you want to have the most recent jpeg image
> advertised when in "standard" mode (currently, nothing is advertised  
> in
> this mode). Sounds like a reasonable suggestion to me.
>
> In the patch you submitted the jpeg is now created twice when in
> "standard" mode. I think it can be rewritten in a more efficient way
> such that  it would generate only one image named after
> 'filename_standard_mode' and then, depending on the mode, either  
> rename
> ("remove") or copy ("standard") it to 'filename_remove_mode'.
>
You're right. I'll sent an optimized version of the patch!

>> Another rather minor annoyance (IMHO;-) is the naming of the
>> continuous output files: ...
>> which makes a lexicographic ordering unnecessary difficult and  
>> usually
>> (depending on the processing tool - in my case mencoder) requires an
>> additional sorting step. Would it make sense to prepend a couple of
>> zeros to the format string (Write.c)?
>
> That is a good idea !
>
> -- 
> Cheers, Thomas.
>
Cheers,
Ole


From schnetter at cct.lsu.edu  Thu Dec  6 11:25:55 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Thu, 6 Dec 2007 11:25:55 -0600
Subject: [Users] non-portable inline problem & c++ void operator
	declaration problem
In-Reply-To: <c89bf5b50712042203q27ce942cx1c2a1f018e8ba089@mail.gmail.com>
References: <c89bf5b50712042203q27ce942cx1c2a1f018e8ba089@mail.gmail.com>
Message-ID: <C32748DD-F325-4ACB-B7E3-E767F427E770@cct.lsu.edu>

On Dec 5, 2007, at 00:03:37, Hee Il Kim wrote:

> Hi all,
>
> Recently I updated Cactus flesh and failed to make building. The  
> two relevant messages are attached below. It occured on the ppc64  
> linux system using XL compilers. I appreciate your help in advance.
>
> Hee Il
>
>
> --  1st one ---
> "/home/hmlee/Cactus/src/include/cctk_Complex.h", line 109.1:  
> 1506-1108 (I) The use of keyword '__inline__' is non-portable.
> "/usr/include/bits/mathinline.h", line 66.58: 1506-1197 (W) The use  
> of ':' in designated initializer syntax is non-portable.

This looks harmless; you can probably ignore it.

> --  2nd one --- 
> Preprocessing /home/hmlee/Cactus/arrangements/AEIThorns/ 
> AHFinderDirect/src/patch
> /ghost_zone.cc
> Compiling /home/hmlee/Cactus/arrangements/AEIThorns/AHFinderDirect/ 
> src/patch/gho
> st_zone.cc
> "/home/hmlee/Cactus/configs/rns_pugh/build/AHFinderDirect/patch/ 
> ghost_zone.cc",
> line 377.8: 1540-0256 (S) A parameter of type "void *" cannot be  
> initialized wit
> h an expression of type "const AHFinderDirect::patch_interp *".


This is probably the only real problem, as it is flagged with "(S)".   
Someone may be able to help you better if you say exactly what  
compiler and what system you are using.  It could be that a cast to  
const is missing.  Jonathan Thornburg is the original author of this  
code and a C++ expert; Jonathan, are you reading this?

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>

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/users/attachments/20071206/bcbb4e69/attachment-0001.bin 

From jthorn at aei.mpg.de  Sun Dec  9 16:55:55 2007
From: jthorn at aei.mpg.de (jthorn at aei.mpg.de)
Date: Sun, 9 Dec 2007 22:55:55 +0000 (GMT)
Subject: [Users] non-portable inline problem & c++ void
 operator	declaration problem
In-Reply-To: <C32748DD-F325-4ACB-B7E3-E767F427E770@cct.lsu.edu>
References: <c89bf5b50712042203q27ce942cx1c2a1f018e8ba089@mail.gmail.com>
	<C32748DD-F325-4ACB-B7E3-E767F427E770@cct.lsu.edu>
Message-ID: <Pine.BSO.4.64.0712092242160.27626@helium.soton.ac.uk>

Hi, all,

On Dec 5, 2007, at 00:03:37, Hee Il Kim wrote:
> 
> Recently I updated Cactus flesh and failed to make building. The two
> relevant messages are attached below. It occured on the ppc64 linux system
> using XL compilers. I appreciate your help in advance.
> 
> Hee Il
> 
> 
> --  1st one ---
> "/home/hmlee/Cactus/src/include/cctk_Complex.h", line 109.1: 1506-1108 (I)
> The use of keyword '__inline__' is non-portable.
> "/usr/include/bits/mathinline.h", line 66.58: 1506-1197 (W) The use of ':'
> in designated initializer syntax is non-portable.
[[...]]

> --  2nd one ---Preprocessing
> /home/hmlee/Cactus/arrangements/AEIThorns/AHFinderDirect/src/patch
> /ghost_zone.cc
> Compiling
> /home/hmlee/Cactus/arrangements/AEIThorns/AHFinderDirect/src/patch/gho
> st_zone.cc
> "/home/hmlee/Cactus/configs/rns_pugh/build/AHFinderDirect/patch/ghost_zone.cc",
> line 377.8: 1540-0256 (S) A parameter of type "void *" cannot be initialized
> wit
> h an expression of type "const AHFinderDirect::patch_interp *".

Looking at the code around 377 (assuming my line numbers match yours),
it's just deleting some objects:
   365  //
   366  // this function destroys an  interpatch_ghost_zone  object.
   367  //
   368  interpatch_ghost_zone::~interpatch_ghost_zone()
   369  {
   370  delete Jacobian_buffer_;
   371  delete Jacobian_y_ipar_posn_;
   372  delete interp_result_buffer_;
   373  delete other_par_;
   374  delete max_ipar_used_;
   375  delete min_ipar_used_;
   376  delete other_iperp_;
   377  delete other_patch_interp_;
   378  }

The builtin C++  delete  operator wants a  void*  pointer, and it
looks like your C++ compiler is complaining about trying to convert
  other_patch_interp_  (which is of type   const AHFinderDirect::patch_interp *)
into a  void* .  Maybe the problem is the const qualifier.  I will
check into what the C standard says, try some test programs, and
hopefully have a fix within a couple of days...

ciao,

-- 
-- Jonathan Thornburg (remove -animal to reply) <J.Thornburg at soton.ac-zebra.uk>
   School of Mathematics, U of Southampton, England
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

From schnetter at cct.lsu.edu  Thu Dec 13 09:33:26 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Thu, 13 Dec 2007 08:33:26 -0700
Subject: [Users] non-portable inline problem & c++ void
	operator	declaration problem
In-Reply-To: <Pine.BSO.4.64.0712092242160.27626@helium.soton.ac.uk>
References: <c89bf5b50712042203q27ce942cx1c2a1f018e8ba089@mail.gmail.com>
	<C32748DD-F325-4ACB-B7E3-E767F427E770@cct.lsu.edu>
	<Pine.BSO.4.64.0712092242160.27626@helium.soton.ac.uk>
Message-ID: <6E0D726E-01B5-4547-902F-FDE3C2F02D47@cct.lsu.edu>

On Dec 9, 2007, at 15:55:55, jthorn at aei.mpg.de wrote:

> Hi, all,
>
> On Dec 5, 2007, at 00:03:37, Hee Il Kim wrote:
>>
>> Recently I updated Cactus flesh and failed to make building. The two
>> relevant messages are attached below. It occured on the ppc64  
>> linux system
>> using XL compilers. I appreciate your help in advance.
>>
>> Hee Il
>>
>>
>> --  1st one ---
>> "/home/hmlee/Cactus/src/include/cctk_Complex.h", line 109.1:  
>> 1506-1108 (I)
>> The use of keyword '__inline__' is non-portable.
>> "/usr/include/bits/mathinline.h", line 66.58: 1506-1197 (W) The  
>> use of ':'
>> in designated initializer syntax is non-portable.
> [[...]]
>
>> --  2nd one ---Preprocessing
>> /home/hmlee/Cactus/arrangements/AEIThorns/AHFinderDirect/src/patch
>> /ghost_zone.cc
>> Compiling
>> /home/hmlee/Cactus/arrangements/AEIThorns/AHFinderDirect/src/patch/ 
>> gho
>> st_zone.cc
>> "/home/hmlee/Cactus/configs/rns_pugh/build/AHFinderDirect/patch/ 
>> ghost_zone.cc",
>> line 377.8: 1540-0256 (S) A parameter of type "void *" cannot be  
>> initialized
>> wit
>> h an expression of type "const AHFinderDirect::patch_interp *".
>
> Looking at the code around 377 (assuming my line numbers match yours),
> it's just deleting some objects:
>    365  //
>    366  // this function destroys an  interpatch_ghost_zone  object.
>    367  //
>    368  interpatch_ghost_zone::~interpatch_ghost_zone()
>    369  {
>    370  delete Jacobian_buffer_;
>    371  delete Jacobian_y_ipar_posn_;
>    372  delete interp_result_buffer_;
>    373  delete other_par_;
>    374  delete max_ipar_used_;
>    375  delete min_ipar_used_;
>    376  delete other_iperp_;
>    377  delete other_patch_interp_;
>    378  }
>
> The builtin C++  delete  operator wants a  void*  pointer, and it
> looks like your C++ compiler is complaining about trying to convert
>   other_patch_interp_  (which is of type   const  
> AHFinderDirect::patch_interp *)
> into a  void* .  Maybe the problem is the const qualifier.  I will
> check into what the C standard says, try some test programs, and
> hopefully have a fix within a couple of days...


Hee-Il,

did you try adding a const-cast, as Jonathan suggested?  If so, did  
it work?

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/ 
~eschnett/

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/users/attachments/20071213/ab54a464/attachment.bin 

From dlleuz at xmission.com  Thu Dec 20 17:43:43 2007
From: dlleuz at xmission.com (rsoares)
Date: Thu, 20 Dec 2007 16:43:43 -0700
Subject: [Users] Compiling EinsteinToolkit
Message-ID: <476AFE2F.2090004@xmission.com>

Hi,

When trying to make EinsteinToolkit I get the errors:

CST error 2:
    -> Unknown parameter type  ' '  for parameter ' periodic '
CST error 3:
    -> Unknown parameter type  ' '  for parameter ' periodic_x '
CST error 4:
    -> Unknown parameter type  ' '  for parameter  ' periodic_y '
CST error 5:
    -> Unknown parameter type  ' '  for parameter  ' periodic_z '
- - - -
gmake[1]:  No rule to make target  . . 
./configs/EinsteinTK/config-data/make.thornlist

from running:  gmake EinsteinTK

Please send me your advice and thanks for your time.  The thornlist is 
below.

Sincerely,

R.Soares

-----------
EinsteinToolkit.th
-----------
# $Id:

!DESC "All thorns from Cactus Einstein Toolkit (Development)"

!REPOSITORY_TYPE pserver
!REPOSITORY_LOCATION cvs.cactuscode.org
!REPOSITORY_NAME /cactus
               
CactusEinstein/ADM
CactusEinstein/ADMAnalysis
CactusEinstein/ADMBase              
CactusEinstein/ADMConstraints     
CactusEinstein/ADMCoupling
CactusEinstein/ADMMacros
CactusEinstein/AHFinder
CactusEinstein/CoordGauge          
CactusEinstein/EvolSimple         
CactusEinstein/Extract  
CactusEinstein/IDAnalyticBH       
CactusEinstein/IDAxiBrillBH       
CactusEinstein/IDBrillData        
CactusEinstein/IDLinearWaves
CactusEinstein/IDSimple
CactusEinstein/Maximal
CactusEinstein/PsiKadelia
CactusEinstein/SpaceMask
CactusEinstein/StaticConformal
CactusEinstein/TimeGeodesic
CactusBase/LocalReduce
CactusBase/CartGrid3D
CactusBase/CoordBase
CactusBase/Boundary
CactusBase/IOUtil
CactusBase/SymBase
CactusBase/Time
CactusElliptic/EllBase


From jtao at cct.lsu.edu  Thu Dec 20 21:43:46 2007
From: jtao at cct.lsu.edu (Jian Tao)
Date: Thu, 20 Dec 2007 21:43:46 -0600
Subject: [Users] Compiling EinsteinToolkit
In-Reply-To: <476AFE2F.2090004@xmission.com>
References: <476AFE2F.2090004@xmission.com>
Message-ID: <476B3672.1070203@cct.lsu.edu>

You need a Cactus driver. To solve the problem, you can add the
following thorns to your thorn list.

CactusPUGH/PUGH
CactusPUGH/PUGHSlab
CactusPUGH/PUGHReduce

Actually, you can use either the uniform
grid driver PUGH, which is distributed with Cactus as the
default driver, or the mesh refinement driver
Carpet (http://www.carpetcode.org/)

Besides PUGH and Carpet, there are several other drivers.
You can find more about them on Cactus website.

Regards,
Jian

rsoares wrote:
> Hi,
> 
> When trying to make EinsteinToolkit I get the errors:
> 
> CST error 2:
>     -> Unknown parameter type  ' '  for parameter ' periodic '
> CST error 3:
>     -> Unknown parameter type  ' '  for parameter ' periodic_x '
> CST error 4:
>     -> Unknown parameter type  ' '  for parameter  ' periodic_y '
> CST error 5:
>     -> Unknown parameter type  ' '  for parameter  ' periodic_z '
> - - - -
> gmake[1]:  No rule to make target  . . 
> ./configs/EinsteinTK/config-data/make.thornlist
> 
> from running:  gmake EinsteinTK
> 
> Please send me your advice and thanks for your time.  The thornlist is 
> below.
> 
> Sincerely,
> 
> R.Soares
> 
> -----------
> EinsteinToolkit.th
> -----------
> # $Id:
> 
> !DESC "All thorns from Cactus Einstein Toolkit (Development)"
> 
> !REPOSITORY_TYPE pserver
> !REPOSITORY_LOCATION cvs.cactuscode.org
> !REPOSITORY_NAME /cactus
>                
> CactusEinstein/ADM
> CactusEinstein/ADMAnalysis
> CactusEinstein/ADMBase              
> CactusEinstein/ADMConstraints     
> CactusEinstein/ADMCoupling
> CactusEinstein/ADMMacros
> CactusEinstein/AHFinder
> CactusEinstein/CoordGauge          
> CactusEinstein/EvolSimple         
> CactusEinstein/Extract  
> CactusEinstein/IDAnalyticBH       
> CactusEinstein/IDAxiBrillBH       
> CactusEinstein/IDBrillData        
> CactusEinstein/IDLinearWaves
> CactusEinstein/IDSimple
> CactusEinstein/Maximal
> CactusEinstein/PsiKadelia
> CactusEinstein/SpaceMask
> CactusEinstein/StaticConformal
> CactusEinstein/TimeGeodesic
> CactusBase/LocalReduce
> CactusBase/CartGrid3D
> CactusBase/CoordBase
> CactusBase/Boundary
> CactusBase/IOUtil
> CactusBase/SymBase
> CactusBase/Time
> CactusElliptic/EllBase
> 
> _______________________________________________
> Users mailing list
> Users at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/users
> 


From dlleuz at xmission.com  Sat Dec 22 21:00:11 2007
From: dlleuz at xmission.com (rsoares)
Date: Sat, 22 Dec 2007 20:00:11 -0700
Subject: [Users] SetupGH.cc has missing member in struct
Message-ID: <476DCF3B.8080200@xmission.com>

Hi,

1.)
I'm  trying to compile EinsteinToolkit but get this error:

Preprocessing /Cactus/arrangements/Carpet/Carpet/src/SetupGH.cc
Compiling /Cactus/arrangements/Carpet/Carpet/src/SetupGH.cc

/Cactus/configs/EinsteinTK/build/Carpet/SetupGH.cc: In function " void 
Carpet::allocate_group_variables(cGH*, int, int, int) " :
/Cactus/configs/EinsteinTK/build/Carpet/SetupGH.cc:1053: error:  " 
struct cGroupDynamicData "  has no member named " activetimelevels "

gmake[3]: *** [SetupGH.cc.o] Error 1
gmake[2]: *** [make.checked] Error 2
gmake[1]: *** [/Cactus/configs/EinsteinTK/lib/libCarpet.a] Error 2
gmake: *** [EinsteinTK] Error 2

2.)
I'm using cvs /cactusdevcvs version 15, and carpet-stable-2 downloaded 
from darc just today so both are current.
Using the "stable" cactus from cvs /cactus same version 15 missing 
pieces in CactusBase/IOUtil/interface.ccl.

3.)
 From previous errors, I had to add to the original thornlist (see below)  *

Thanks, anyone who can please help.

-R.Soares

---------
EinsteinToolkit.th
---------
# $Id:

!DESC "All thorns from Cactus Einstein Toolkit (Development)"

!REPOSITORY_TYPE pserver
!REPOSITORY_LOCATION cvs.cactuscode.org
!REPOSITORY_NAME /cactus
               
CactusEinstein/ADM
CactusEinstein/ADMAnalysis
CactusEinstein/ADMBase              
CactusEinstein/ADMConstraints     
CactusEinstein/ADMCoupling
CactusEinstein/ADMMacros
CactusEinstein/AHFinder
CactusEinstein/CoordGauge          
CactusEinstein/EvolSimple         
CactusEinstein/Extract  
CactusEinstein/IDAnalyticBH       
CactusEinstein/IDAxiBrillBH       
CactusEinstein/IDBrillData        
CactusEinstein/IDLinearWaves
CactusEinstein/IDSimple
CactusEinstein/Maximal
CactusEinstein/PsiKadelia
CactusEinstein/SpaceMask
CactusEinstein/StaticConformal
CactusEinstein/TimeGeodesic
CactusBase/LocalReduce
CactusBase/CartGrid3D  *
CactusBase/CoordBase  *
CactusBase/Boundary   *
CactusBase/IOUtil  *
CactusBase/SymBase *
CactusBase/Time *
CactusElliptic/EllBase  *
Carpet/Carpet  *
Carpet/CarpetLib  *


From jtao at cct.lsu.edu  Sat Dec 22 23:57:32 2007
From: jtao at cct.lsu.edu (Jian Tao)
Date: Sat, 22 Dec 2007 23:57:32 -0600
Subject: [Users] SetupGH.cc has missing member in struct
In-Reply-To: <476DCF3B.8080200@xmission.com>
References: <476DCF3B.8080200@xmission.com>
Message-ID: <476DF8CC.9060508@cct.lsu.edu>

CactusDev + [ carpet-stable-3 or carpet-devel ] is probably
the combination you want to use unless you really want to use 
carpet-stable-2 for some reason. Notice that carpet-stable-2
is marked as "outdated" on Carpet website.

As far as I know, the stable version of the Cactus toolkit is
not updated to be compatible with Carpet stable 2 and later
version.

Regards,
Jian

rsoares wrote:
> Hi,
> 
> 1.)
> I'm  trying to compile EinsteinToolkit but get this error:
> 
> Preprocessing /Cactus/arrangements/Carpet/Carpet/src/SetupGH.cc
> Compiling /Cactus/arrangements/Carpet/Carpet/src/SetupGH.cc
> 
> /Cactus/configs/EinsteinTK/build/Carpet/SetupGH.cc: In function " void 
> Carpet::allocate_group_variables(cGH*, int, int, int) " :
> /Cactus/configs/EinsteinTK/build/Carpet/SetupGH.cc:1053: error:  " 
> struct cGroupDynamicData "  has no member named " activetimelevels "
> 
> gmake[3]: *** [SetupGH.cc.o] Error 1
> gmake[2]: *** [make.checked] Error 2
> gmake[1]: *** [/Cactus/configs/EinsteinTK/lib/libCarpet.a] Error 2
> gmake: *** [EinsteinTK] Error 2
> 
> 2.)
> I'm using cvs /cactusdevcvs version 15, and carpet-stable-2 downloaded 
> from darc just today so both are current.
> Using the "stable" cactus from cvs /cactus same version 15 missing 
> pieces in CactusBase/IOUtil/interface.ccl.
> 
> 3.)
>  From previous errors, I had to add to the original thornlist (see below)  *
> 
> Thanks, anyone who can please help.
> 
> -R.Soares
> 
> ---------
> EinsteinToolkit.th
> ---------
> # $Id:
> 
> !DESC "All thorns from Cactus Einstein Toolkit (Development)"
> 
> !REPOSITORY_TYPE pserver
> !REPOSITORY_LOCATION cvs.cactuscode.org
> !REPOSITORY_NAME /cactus
>                
> CactusEinstein/ADM
> CactusEinstein/ADMAnalysis
> CactusEinstein/ADMBase              
> CactusEinstein/ADMConstraints     
> CactusEinstein/ADMCoupling
> CactusEinstein/ADMMacros
> CactusEinstein/AHFinder
> CactusEinstein/CoordGauge          
> CactusEinstein/EvolSimple         
> CactusEinstein/Extract  
> CactusEinstein/IDAnalyticBH       
> CactusEinstein/IDAxiBrillBH       
> CactusEinstein/IDBrillData        
> CactusEinstein/IDLinearWaves
> CactusEinstein/IDSimple
> CactusEinstein/Maximal
> CactusEinstein/PsiKadelia
> CactusEinstein/SpaceMask
> CactusEinstein/StaticConformal
> CactusEinstein/TimeGeodesic
> CactusBase/LocalReduce
> CactusBase/CartGrid3D  *
> CactusBase/CoordBase  *
> CactusBase/Boundary   *
> CactusBase/IOUtil  *
> CactusBase/SymBase *
> CactusBase/Time *
> CactusElliptic/EllBase  *
> Carpet/Carpet  *
> Carpet/CarpetLib  *
> 
> _______________________________________________
> Users mailing list
> Users at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/users
> 


From dlleuz at xmission.com  Tue Dec 25 20:40:08 2007
From: dlleuz at xmission.com (rsoares)
Date: Tue, 25 Dec 2007 19:40:08 -0700
Subject: [Users] Param Files for Testing Executables
Message-ID: <4771BF08.608@xmission.com>

Hi,

I have built several executables but are there test files.par anywhere 
to give them?

example runs:

1.)
$> ../exe/cactus_testHelloWorld

output:
$>  Usage: ../exe/cactus_testHelloWorld [-h] [-O] [-o paramname] [-W n] 
[-E n] [-r[o|e|oe|eo]] [-T] [-t name] [-parameter-level <level>] [-v] 
<parameter_file_name>

2.)
$> ../exe/cactus_testHelloWorld  
arrangements/CactusExamples/HelloWorld/par/HelloWorld.par

output:
$>  
--------------------------------------------------------------------------------

       10                                 
  1   0101       ************************ 
  01  1010 10      The Cactus Code V4.0   
 1010 1101 011      www.cactuscode.org    
  1001 100101    ************************ 
    00010101                              
     100011     (c) Copyright The Authors 
      0100      GNU Licensed. No Warranty 
      0101                                

--------------------------------------------------------------------------------

Cactus version: 4.0.b15
Compile date:   Dec 25 2007 (19:11:34)
Run date:       Dec 25 2007 (19:31:11)
Run host:       rscompaq2
Executable:     ./exe/cactus_testHelloWorld
Parameter file: arrangements/CactusExamples/HelloWorld/par/HelloWorld.par
--------------------------------------------------------------------------------

Activating thorn Cactus...Success -> active implementation Cactus
WARNING level 0 in thorn Cactus processor 0
  (line 80 of 
/home/robyn/CactusDev/configs/testHelloWorld/build/Cactus/main/ProcessParameterDatabase.c): 

  -> Cannot open parameter file 
'arrangements/CactusExamples/HelloWorld/par/HelloWorld.par'
[0] MPI Abort by user Aborting program !
[0] Aborting program!
p0_25943:  p4_error: : 0


Thanks for your time.

-R.Soares



From jtao at cct.lsu.edu  Tue Dec 25 21:00:15 2007
From: jtao at cct.lsu.edu (Jian Tao)
Date: Tue, 25 Dec 2007 21:00:15 -0600
Subject: [Users] Param Files for Testing Executables
In-Reply-To: <4771BF08.608@xmission.com>
References: <4771BF08.608@xmission.com>
Message-ID: <4771C3BF.2010202@cct.lsu.edu>

It seems the path to your parameter file is wrong.

Go to the directory where you tried and
run

$>../exe/cactus_testHelloWorld 
../arrangements/CactusExamples/HelloWorld/par/HelloWorld.par

Jian
rsoares wrote:
> Hi,
> 
> I have built several executables but are there test files.par anywhere 
> to give them?
> 
> example runs:
> 
> 1.)
> $> ../exe/cactus_testHelloWorld
> 
> output:
> $>  Usage: ../exe/cactus_testHelloWorld [-h] [-O] [-o paramname] [-W n] 
> [-E n] [-r[o|e|oe|eo]] [-T] [-t name] [-parameter-level <level>] [-v] 
> <parameter_file_name>
> 
> 2.)
> $> ../exe/cactus_testHelloWorld  
> arrangements/CactusExamples/HelloWorld/par/HelloWorld.par
> 
> output:
> $>  
> --------------------------------------------------------------------------------
> 
>        10                                 
>   1   0101       ************************ 
>   01  1010 10      The Cactus Code V4.0   
>  1010 1101 011      www.cactuscode.org    
>   1001 100101    ************************ 
>     00010101                              
>      100011     (c) Copyright The Authors 
>       0100      GNU Licensed. No Warranty 
>       0101                                
> 
> --------------------------------------------------------------------------------
> 
> Cactus version: 4.0.b15
> Compile date:   Dec 25 2007 (19:11:34)
> Run date:       Dec 25 2007 (19:31:11)
> Run host:       rscompaq2
> Executable:     ./exe/cactus_testHelloWorld
> Parameter file: arrangements/CactusExamples/HelloWorld/par/HelloWorld.par
> --------------------------------------------------------------------------------
> 
> Activating thorn Cactus...Success -> active implementation Cactus
> WARNING level 0 in thorn Cactus processor 0
>   (line 80 of 
> /home/robyn/CactusDev/configs/testHelloWorld/build/Cactus/main/ProcessParameterDatabase.c): 
> 
>   -> Cannot open parameter file 
> 'arrangements/CactusExamples/HelloWorld/par/HelloWorld.par'
> [0] MPI Abort by user Aborting program !
> [0] Aborting program!
> p0_25943:  p4_error: : 0
> 
> 
> Thanks for your time.
> 
> -R.Soares
> 
> 
> _______________________________________________
> Users mailing list
> Users at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/users
> 


From baiotti at ea.c.u-tokyo.ac.jp  Tue Dec 25 21:03:42 2007
From: baiotti at ea.c.u-tokyo.ac.jp (Luca Baiotti)
Date: Wed, 26 Dec 2007 12:03:42 +0900
Subject: [Users] Param Files for Testing Executables
In-Reply-To: <4771BF08.608@xmission.com>
References: <4771BF08.608@xmission.com>
Message-ID: <4771C48E.70601@ea.c.u-tokyo.ac.jp>

rsoares wrote:
> Hi,
> 
> I have built several executables but are there test files.par anywhere 
> to give them?

Several thorns have example parameter files in the respective directories:

arrangements/<arrangement-name>/<thorn-name>/test/


Luca