From tradke at aei.mpg.de  Fri Nov  7 10:22:41 2008
From: tradke at aei.mpg.de (Thomas Radke)
Date: Fri, 07 Nov 2008 17:22:41 +0100
Subject: [Developers] new configure option to enable/disable OpenMP support
Message-ID: <49146B51.8070106@aei.mpg.de>

Hi,

I propose the attached patch which introduces a new configure option 
OpenMP=yes|no to enable/disable OpenMP compilation of a Cactus 
configuration. So far Intel, PathScale, and GNU compilers under Linux 
and IBM compilers under AIX are supported.

-- 
Cheers, Thomas.


--- StripMime Report -- processed MIME parts ---
multipart/mixed
  text/plain (text body -- kept)
  text/x-patch
---

From schnetter at cct.lsu.edu  Fri Nov  7 14:14:14 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Fri, 7 Nov 2008 15:14:14 -0500
Subject: [Developers] HydroBase infrastructure
Message-ID: <6664A488-484F-4C71-93E2-E83145D83EE8@cct.lsu.edu>

Dear GR Hydro Developers

Tanja Bode, Roland Haas, Frank L?ffler, and I have taken up again the  
idea of a common HydroBase thorn.  This thorn would form a common  
basis for all or most GR hydro codes in much the same way that ADMBase  
is a common basis for most spacetime codes.  It would thus simplify  
writing initial data or analysis methods for GR hydro, and by  
explicitly providing standards defining e.g. what quantities initial  
data routines must provide would also prevent certain kinds of errors.

We have designed a prototype for a HydroBase thorn and are now looking  
for feedback.  You can find a snapshot of the prototype at <http://www.cct.lsu.edu/~knarf/HydroBase.tar.bz2 
 >.

Our current design has the following feature details:
- a common definition for the primitive variables
- the conserved (evolved) variables are still defined by the hydro  
evolution thorn
- common schedule groups for initial data, RHS calculation, boundary  
conditions, etc.
- common parameters to choose the number of time levels, hydro  
prolongation method, etc.
- HydroBase does not contain any source code
- initial data are supposed to be provided for the primitive variables  
only
- the pressure is considered a primitive variable

We plan to extend this thorn to:
- include variables for magnetic fields
- use TmunuBase as hydro interface (instead of CalcTmunu.inc)
- provide routines calculating Tmunu from the primitive variables

We hope that HydroBase can become a community standard.  Given the  
prevalence of Whisky, we kept things compatible with Whisky as much as  
possible, and we estimate that it should be very easy to modify Whisky  
to make use of HydroBase.  We're especially looking for feed from  
developers of other GR hydro codes.

Tanja, Roland, Frank, 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: 194 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20081107/299007e5/attachment.bin 

From jtao at cct.lsu.edu  Fri Nov  7 14:54:07 2008
From: jtao at cct.lsu.edu (Jian Tao)
Date: Fri, 07 Nov 2008 14:54:07 -0600
Subject: [Developers] HydroBase infrastructure
In-Reply-To: <6664A488-484F-4C71-93E2-E83145D83EE8@cct.lsu.edu>
References: <6664A488-484F-4C71-93E2-E83145D83EE8@cct.lsu.edu>
Message-ID: <4914AAEF.5030809@cct.lsu.edu>

I noticed that in the prototype HydroBase has a direct dependence on
MethodOfLines.

Is it necessary ? Shouldn't it be the users' thorns to take care of
the evolution ?

Regards,
Jian

Erik Schnetter wrote:
> Dear GR Hydro Developers
> 
> Tanja Bode, Roland Haas, Frank L?ffler, and I have taken up again the 
> idea of a common HydroBase thorn.  This thorn would form a common basis 
> for all or most GR hydro codes in much the same way that ADMBase is a 
> common basis for most spacetime codes.  It would thus simplify writing 
> initial data or analysis methods for GR hydro, and by explicitly 
> providing standards defining e.g. what quantities initial data routines 
> must provide would also prevent certain kinds of errors.
> 
> We have designed a prototype for a HydroBase thorn and are now looking 
> for feedback.  You can find a snapshot of the prototype at 
> <http://www.cct.lsu.edu/~knarf/HydroBase.tar.bz2>.
> 
> Our current design has the following feature details:
> - a common definition for the primitive variables
> - the conserved (evolved) variables are still defined by the hydro 
> evolution thorn
> - common schedule groups for initial data, RHS calculation, boundary 
> conditions, etc.
> - common parameters to choose the number of time levels, hydro 
> prolongation method, etc.
> - HydroBase does not contain any source code
> - initial data are supposed to be provided for the primitive variables only
> - the pressure is considered a primitive variable
> 
> We plan to extend this thorn to:
> - include variables for magnetic fields
> - use TmunuBase as hydro interface (instead of CalcTmunu.inc)
> - provide routines calculating Tmunu from the primitive variables
> 
> We hope that HydroBase can become a community standard.  Given the 
> prevalence of Whisky, we kept things compatible with Whisky as much as 
> possible, and we estimate that it should be very easy to modify Whisky 
> to make use of HydroBase.  We're especially looking for feed from 
> developers of other GR hydro codes.
> 
> Tanja, Roland, Frank, Erik
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers


From baiotti at ea.c.u-tokyo.ac.jp  Sat Nov  8 14:59:34 2008
From: baiotti at ea.c.u-tokyo.ac.jp (Baiotti Luca)
Date: Sun, 09 Nov 2008 05:59:34 +0900
Subject: [Developers] parfile-error warnings
Message-ID: <4915FDB6.5000402@ea.c.u-tokyo.ac.jp>

Hello,

warnings like:

CCTKi_SetParameter: Error at line 11 in parameter file ....par while 
activating thorns
WARNING level 0 in thorn Cactus processor 277 host qb540
   (line 93 of 
/home/baiotti/Cactus/configs/whisky/build/Cactus/main/SetParams.c):
   ->WARNING level 0 in thorn Cactus processor 131 host ...


are printed by each processor. If all processors read the same parfile, 
could Cactus print only one warning/error message instead of one per 
processor?


Ciao,

Luca

From tradke at aei.mpg.de  Mon Nov 10 03:17:20 2008
From: tradke at aei.mpg.de (Thomas Radke)
Date: Mon, 10 Nov 2008 10:17:20 +0100
Subject: [Developers] parfile-error warnings
In-Reply-To: <4915FDB6.5000402@ea.c.u-tokyo.ac.jp>
References: <4915FDB6.5000402@ea.c.u-tokyo.ac.jp>
Message-ID: <4917FC20.1040909@aei.mpg.de>

Baiotti Luca wrote:
> Hello,
> 
> warnings like:
> 
> CCTKi_SetParameter: Error at line 11 in parameter file ....par while 
> activating thorns
> WARNING level 0 in thorn Cactus processor 277 host qb540
>    (line 93 of 
> /home/baiotti/Cactus/configs/whisky/build/Cactus/main/SetParams.c):
>    ->WARNING level 0 in thorn Cactus processor 131 host ...
> 
> 
> are printed by each processor. If all processors read the same parfile, 
> could Cactus print only one warning/error message instead of one per 
> processor?

You could simply ask Cactus to redirect stdout/stderr of each processor 
into a separate file, using the '--redirect[o|e|oe|eo]' command line option.

-- 
Cheers, Thomas.

From i.hawke at soton.ac.uk  Mon Nov 10 04:17:04 2008
From: i.hawke at soton.ac.uk (I.Hawke)
Date: Mon, 10 Nov 2008 10:17:04 +0000
Subject: [Developers] HydroBase infrastructure
In-Reply-To: <6664A488-484F-4C71-93E2-E83145D83EE8@cct.lsu.edu>
References: <6664A488-484F-4C71-93E2-E83145D83EE8@cct.lsu.edu>
Message-ID: <49180A20.4080100@soton.ac.uk>

As there are a number of ways in which Cactus has improved since Whisky 
was first written, I think following too closely to Whisky is a mistake. 
There are points I would change.

- As Jian says the MoL related bits in param.ccl should go.
- I would recommend making the velocity a vector grid function vel(3) 
instead of vel[xyz] to simplify operations.
- I would recommend splitting the primitive variables into the three 
"genuine" primitive variables and an "auxilliary" group; e.g., the 
Lorentz factor is really an auxilliary variable computed from the 
velocity etc. and so does not have the same "status" as other primitive 
variables.
- If you really want to be general the the three genuine primitive 
variables should be unspecified as well - just another vector group. 
This would allow different implementations to use, e.g., {rho, eps, P} 
or {rho, eps, s} or... as controlled by some parameter within Hydrobase. 
Well, not controlled - this would be a consistency check for initial 
data and evolution thorns.
- It makes no sense to put references to conserved variables in the 
schedule.ccl if there are no conserved variables defined. If you're 
going to assume that conserved variables will be used then define them - 
otherwise drop the statements from the schedule.ccl! Ditto the 
atmosphere statements.
- The schedule.ccl also implicitly assumes that a particular EOS Base 
implementation is used - this should be clarified.

I'll keep looking at it. At the moment I waver between saying that the 
thorn should add more code - e.g., give more structure to the use of 
conserved variables and the EOS - or to remove more. If ADMBase is 
really the model it should probably be the latter.

Best,

Ian

Erik Schnetter wrote:
> Dear GR Hydro Developers
>
> Tanja Bode, Roland Haas, Frank L?ffler, and I have taken up again the
> idea of a common HydroBase thorn.  This thorn would form a common
> basis for all or most GR hydro codes in much the same way that ADMBase
> is a common basis for most spacetime codes.  It would thus simplify
> writing initial data or analysis methods for GR hydro, and by
> explicitly providing standards defining e.g. what quantities initial
> data routines must provide would also prevent certain kinds of errors.
>
> We have designed a prototype for a HydroBase thorn and are now looking
> for feedback.  You can find a snapshot of the prototype at <http://www.cct.lsu.edu/~knarf/HydroBase.tar.bz2
>  >.
>
> Our current design has the following feature details:
> - a common definition for the primitive variables
> - the conserved (evolved) variables are still defined by the hydro
> evolution thorn
> - common schedule groups for initial data, RHS calculation, boundary
> conditions, etc.
> - common parameters to choose the number of time levels, hydro
> prolongation method, etc.
> - HydroBase does not contain any source code
> - initial data are supposed to be provided for the primitive variables
> only
> - the pressure is considered a primitive variable
>
> We plan to extend this thorn to:
> - include variables for magnetic fields
> - use TmunuBase as hydro interface (instead of CalcTmunu.inc)
> - provide routines calculating Tmunu from the primitive variables
>
> We hope that HydroBase can become a community standard.  Given the
> prevalence of Whisky, we kept things compatible with Whisky as much as
> possible, and we estimate that it should be very easy to modify Whisky
> to make use of HydroBase.  We're especially looking for feed from
> developers of other GR hydro codes.
>
> Tanja, Roland, Frank, 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.
>
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>   




From baiotti at ea.c.u-tokyo.ac.jp  Mon Nov 10 06:59:15 2008
From: baiotti at ea.c.u-tokyo.ac.jp (Baiotti Luca)
Date: Mon, 10 Nov 2008 21:59:15 +0900
Subject: [Developers] parfile-error warnings
In-Reply-To: <4917FC20.1040909@aei.mpg.de>
References: <4915FDB6.5000402@ea.c.u-tokyo.ac.jp> <4917FC20.1040909@aei.mpg.de>
Message-ID: <49183023.50401@ea.c.u-tokyo.ac.jp>

Thomas Radke wrote:
> Baiotti Luca wrote:
>> Hello,
>>
>> warnings like:
>>
>> CCTKi_SetParameter: Error at line 11 in parameter file ....par while 
>> activating thorns
>> WARNING level 0 in thorn Cactus processor 277 host qb540
>>    (line 93 of 
>> /home/baiotti/Cactus/configs/whisky/build/Cactus/main/SetParams.c):
>>    ->WARNING level 0 in thorn Cactus processor 131 host ...
>>
>>
>> are printed by each processor. If all processors read the same parfile, 
>> could Cactus print only one warning/error message instead of one per 
>> processor?
> 
> You could simply ask Cactus to redirect stdout/stderr of each processor 
> into a separate file, using the '--redirect[o|e|oe|eo]' command line option.

There are other error messages (later during the evolution) which I 
would like to see in one single error file for all processors (the 
messages are produced only by a few processors), so I would still prefer 
to have only one stderr/out file and to reduce the number of useless 
messages (I assume that the same error message repeated from all 
processors is not useful, is it?). OK?

Luca


From knarf at cct.lsu.edu  Mon Nov 10 09:37:51 2008
From: knarf at cct.lsu.edu (Frank Loeffler)
Date: Mon, 10 Nov 2008 09:37:51 -0600
Subject: [Developers] HydroBase infrastructure
In-Reply-To: <49180A20.4080100@soton.ac.uk>
References: <6664A488-484F-4C71-93E2-E83145D83EE8@cct.lsu.edu>
	<49180A20.4080100@soton.ac.uk>
Message-ID: <20081110153751.GS1462@numrel07.cct.lsu.edu>

Hi,

On Mon, Nov 10, 2008 at 10:17:04AM +0000, I.Hawke wrote:
> - As Jian says the MoL related bits in param.ccl should go.

I agree. It seems those are only unused parts anyway.

However, some groups should be scheduled in relation to MoL groups. I
assume that most codes use MoL and even if some are not, they do not
have to schedule something in those groups and schedule things
themselfes - or we can then see how to unify this once such a code wants
to use HydroBase.

> - I would recommend making the velocity a vector grid function vel(3) 
> instead of vel[xyz] to simplify operations.

It really would and we thought about that. We decided against it because
it would require too many changes in existing thorns, e.g. Whisky.

On the other hand I agree that this would be a good idea. I hope that
some other Whisky developers than us two agree to change Whisky in that
way. If not, I would rather see a "moderately good" version of HydroBase
which is used than a really nice one, but which is not used (by Whisky
in this case).

Having written that: I think some #defines might do the trick rather
easily for Whisky.

> - I would recommend splitting the primitive variables into the three 
> "genuine" primitive variables and an "auxilliary" group; e.g., the 
> Lorentz factor is really an auxilliary variable computed from the 
> velocity etc. and so does not have the same "status" as other primitive 
> variables.

A good idea.

> - If you really want to be general the the three genuine primitive 
> variables should be unspecified as well - just another vector group. 
> This would allow different implementations to use, e.g., {rho, eps, P} 
> or {rho, eps, s} or... as controlled by some parameter within Hydrobase. 

When the names are different and nicely long, it should be possible to
use #defines to produce more readable code in the implementations.

> Well, not controlled - this would be a consistency check for initial 
> data and evolution thorns.

There could be a keyword parameter which implementations can extend and
thorns can test against.

> - It makes no sense to put references to conserved variables in the 
> schedule.ccl if there are no conserved variables defined. If you're 
> going to assume that conserved variables will be used then define them - 

Assuming that there are conserves variables does not mean to know which
are there and how they should be defined.
At the moment there are only some groups defines which can be used to
schedule Con2Prim and Prim2Con of the implementations. It does not mean
that they have to be used.

> - The schedule.ccl also implicitly assumes that a particular EOS Base 
> implementation is used - this should be clarified.

Oh, yes. This is just a leftover in the banner scheduling and can safely
be removed. Thanks.

> I'll keep looking at it. At the moment I waver between saying that the 
> thorn should add more code - e.g., give more structure to the use of 
> conserved variables and the EOS - or to remove more. If ADMBase is 
> really the model it should probably be the latter.

HydroBase should be the common ground for hydrocodes within Cactus. In
this sense, it should be common to ADMBase. That does not mean that the
structure has to be the same or that it could not contain more than the
'simple' ADMBase.

You have seen that HydroBase at the moment very much follows the lines
of Whisky. While trying to be general, this was done on purpose to make
the use of HydroBase for Whisky easy. And this is also why we
specifically ask for opinions of developers of other hydrocodes. Nothing
in the current version is fixed, all is open for discussion and can
be changed. What I fear is that we make it too general, thus awkward to
use and in the end without other codes using this generality.

Frank


From schnetter at cct.lsu.edu  Mon Nov 10 10:56:51 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 10 Nov 2008 10:56:51 -0600
Subject: [Developers] parfile-error warnings
In-Reply-To: <4915FDB6.5000402@ea.c.u-tokyo.ac.jp>
References: <4915FDB6.5000402@ea.c.u-tokyo.ac.jp>
Message-ID: <87109FFF-ECAF-436E-94A3-11197DB9F758@cct.lsu.edu>

On Nov 8, 2008, at 14:59:34, Baiotti Luca wrote:

> Hello,
>
> warnings like:
>
> CCTKi_SetParameter: Error at line 11 in parameter file ....par while
> activating thorns
> WARNING level 0 in thorn Cactus processor 277 host qb540
>  (line 93 of
> /home/baiotti/Cactus/configs/whisky/build/Cactus/main/SetParams.c):
>  ->WARNING level 0 in thorn Cactus processor 131 host ...
>
>
> are printed by each processor. If all processors read the same  
> parfile,
> could Cactus print only one warning/error message instead of one per
> processor?

The idea here (and in other, similar places) in Cactus is that  
warnings generated by any processor are displayed on the root  
processor, since warnings are important.

What you are probably looking for is a possibility to display a  
warning only on the root processor.  One could implement this here  
quickly with an if statement about the CCTK_WARN call.  A more general  
mechanism would be more complex if it has to ensure that no warnings  
are lost.

Another annoying message is the very first message "setting warning  
level to...", displayed 12288 times if running on that many processors.

-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: 194 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20081110/d77fd4d0/attachment.bin 

From i.hawke at soton.ac.uk  Mon Nov 10 11:58:37 2008
From: i.hawke at soton.ac.uk (I.Hawke)
Date: Mon, 10 Nov 2008 17:58:37 +0000
Subject: [Developers] HydroBase infrastructure
In-Reply-To: <20081110153751.GS1462@numrel07.cct.lsu.edu>
References: <6664A488-484F-4C71-93E2-E83145D83EE8@cct.lsu.edu>	<49180A20.4080100@soton.ac.uk>
	<20081110153751.GS1462@numrel07.cct.lsu.edu>
Message-ID: <4918764D.1040006@soton.ac.uk>

Frank Loeffler wrote:
> However, some groups should be scheduled in relation to MoL groups. I
> assume that most codes use MoL and even if some are not, they do not
> have to schedule something in those groups and schedule things
> themselfes - or we can then see how to unify this once such a code wants
> to use HydroBase.
>
>   
Indeed - the schedule parts are harmless.
>> - I would recommend making the velocity a vector grid function vel(3)
>> instead of vel[xyz] to simplify operations.
>>     
>
> It really would and we thought about that. We decided against it because
> it would require too many changes in existing thorns, e.g. Whisky.
>
> On the other hand I agree that this would be a good idea. I hope that
> some other Whisky developers than us two agree to change Whisky in that
> way. If not, I would rather see a "moderately good" version of HydroBase
> which is used than a really nice one, but which is not used (by Whisky
> in this case).
>
> Having written that: I think some #defines might do the trick rather
> easily for Whisky.
>   
If there is any chance of it happening then it should go in from the 
start, or that's just more obstacles to later change. But some input 
either from Wolfgang about the Pizza code, or one of the MHD codes, 
would also be necessary before making the change.
>> - If you really want to be general the the three genuine primitive
>> variables should be unspecified as well - just another vector group.
>> This would allow different implementations to use, e.g., {rho, eps, P}
>> or {rho, eps, s} or... as controlled by some parameter within Hydrobase.
>>     
>
> When the names are different and nicely long, it should be possible to
> use #defines to produce more readable code in the implementations.
>   
The main point with this is to clarify what are the fundamental 
variables in any implementation.
>> - It makes no sense to put references to conserved variables in the
>> schedule.ccl if there are no conserved variables defined. If you're
>> going to assume that conserved variables will be used then define them -
>>     
>
> Assuming that there are conserves variables does not mean to know which
> are there and how they should be defined.
>   
But the choice of conserved variables is considerably more constrained 
than that of the primitive. Also, you may want to allow for 
implementations that do not consider the conserved variables at all.
>> I'll keep looking at it. At the moment I waver between saying that the
>> thorn should add more code - e.g., give more structure to the use of
>> conserved variables and the EOS - or to remove more. If ADMBase is
>> really the model it should probably be the latter.
>>     
>
> HydroBase should be the common ground for hydrocodes within Cactus. In
> this sense, it should be common to ADMBase. That does not mean that the
> structure has to be the same or that it could not contain more than the
> 'simple' ADMBase.
What I meant by this was that the simplest, most general "base" thorn 
would contain no reference to conserved variables at all - this is 
closest to the way that ADMBase doesn't include conformal factors etc.

Ian



From knarf at cct.lsu.edu  Mon Nov 10 12:44:54 2008
From: knarf at cct.lsu.edu (Frank Loeffler)
Date: Mon, 10 Nov 2008 12:44:54 -0600
Subject: [Developers] HydroBase infrastructure
In-Reply-To: <4918764D.1040006@soton.ac.uk>
References: <6664A488-484F-4C71-93E2-E83145D83EE8@cct.lsu.edu>
	<49180A20.4080100@soton.ac.uk>
	<20081110153751.GS1462@numrel07.cct.lsu.edu>
	<4918764D.1040006@soton.ac.uk>
Message-ID: <20081110184454.GV1462@numrel07.cct.lsu.edu>

On Mon, Nov 10, 2008 at 05:58:37PM +0000, I.Hawke wrote:
> If there is any chance of it happening then it should go in from the 
> start, or that's just more obstacles to later change. But some input 
> either from Wolfgang about the Pizza code, or one of the MHD codes, 
> would also be necessary before making the change.

> But the choice of conserved variables is considerably more constrained 
> than that of the primitive. Also, you may want to allow for 
> implementations that do not consider the conserved variables at all.

The current version should allow this, as Con2Prim and Prim2Con are only
scheduling groups. They could be left empty. And they are not too many
to bloat a code not usimg them by much.

> What I meant by this was that the simplest, most general "base" thorn 
> would contain no reference to conserved variables at all - this is 
> closest to the way that ADMBase doesn't include conformal factors etc.

Yes, that would be one 'extreme'. This discussion is meant to get
input whether this, or something else more specific is what people want.

So: please all let us know what you think.

Frank


From bzink at cct.lsu.edu  Mon Nov 10 12:50:34 2008
From: bzink at cct.lsu.edu (Burkhard Zink)
Date: Mon, 10 Nov 2008 12:50:34 -0600
Subject: [Developers] HydroBase infrastructure
In-Reply-To: <20081110184454.GV1462@numrel07.cct.lsu.edu>
References: <6664A488-484F-4C71-93E2-E83145D83EE8@cct.lsu.edu>	<49180A20.4080100@soton.ac.uk>	<20081110153751.GS1462@numrel07.cct.lsu.edu>	<4918764D.1040006@soton.ac.uk>
	<20081110184454.GV1462@numrel07.cct.lsu.edu>
Message-ID: <4918827A.5000308@cct.lsu.edu>



Frank Loeffler wrote:
> On Mon, Nov 10, 2008 at 05:58:37PM +0000, I.Hawke wrote:

>> What I meant by this was that the simplest, most general "base" thorn 
>> would contain no reference to conserved variables at all - this is 
>> closest to the way that ADMBase doesn't include conformal factors etc.
> 
> Yes, that would be one 'extreme'. This discussion is meant to get
> input whether this, or something else more specific is what people want.
> 
> So: please all let us know what you think.

I would suggest going for the minimal approach first. The Typhon code 
works mostly similar to Whisky and other HD/MHD codes out there, so 
adapting to primitive storage externally, and some scheduling bins, 
should be easily possible.

We don't use a vector-type group for velocities, but given that ADMBase 
and also the BSSN thorns all seem to go with the simple "group-tag" 
approach and explicit component names, that seems to be consistent.

- B

From sbrandt at cct.lsu.edu  Tue Nov 25 15:33:53 2008
From: sbrandt at cct.lsu.edu (Steven R Brandt)
Date: Tue, 25 Nov 2008 15:33:53 -0600
Subject: [Developers] FONLY, F90ONLY
Message-ID: <492C6F41.5040506@cct.lsu.edu>

Recently, I attempted to compile Cactus on a SiCortex using pathscale 
compilers. This qualified as a "linux" architecture, but I needed a way 
to supply a different flags for .F and .F90 files. My solution was to 
create two new variables in make.config.rules.in that could be passed to 
the fortran compiler:

I then set the following in my config:
 FONLY = -fixedform
 F90ONLY = -freeform

Does this seem like a useful modification to the Cactus flesh?

Cheers,
Steve

$ cvs diff lib/make/make.config.rules.in
Index: lib/make/make.config.rules.in
===================================================================
RCS file: /cactusdevcvs/Cactus/lib/make/make.config.rules.in,v
retrieving revision 1.62
diff -r1.62 make.config.rules.in
135c135
< if test "$(F90)" = "none" ; then echo "There is no Fortran 90 compiler 
available.  Aborting." ; exit 1 ; fi ; current_wd=`$(GET_WD)` ; cd 
$(SCRATCH_BUILD) ; $(F90) $(F90FLAGS) 
$(FCOMPILEONLY)$(OPTIONSEP)$$current_wd$(DIRSEP)$@ 
$$current_wd$(DIRSEP)$(basename $(notdir $<)).f
---
 > if test "$(F90)" = "none" ; then echo "There is no Fortran 90 
compiler available.  Aborting." ; exit 1 ; fi ; current_wd=`$(GET_WD)` ; 
cd $(SCRATCH_BUILD) ; $(F90) $(FONLY) $(F90FLAGS) 
$(FCOMPILEONLY)$(OPTIONSEP)$$current_wd$(DIRSEP)$@ 
$$current_wd$(DIRSEP)$(basename $(notdir $<)).f
148c148
< if test "$(F90)" = "none" ; then echo "There is no Fortran 90 compiler 
available.  Aborting." ; exit 1 ; fi ; current_wd=`$(GET_WD)` ; cd 
$(SCRATCH_BUILD) ; $(F90) $(F90FLAGS) 
$(FCOMPILEONLY)$(OPTIONSEP)$$current_wd$(DIRSEP)$@ 
$$current_wd$(DIRSEP)$(basename $(notdir $<)).$(F90_SUFFIX)
---
 > if test "$(F90)" = "none" ; then echo "There is no Fortran 90 
compiler available.  Aborting." ; exit 1 ; fi ; current_wd=`$(GET_WD)` ; 
cd $(SCRATCH_BUILD) ; $(F90) $(F90ONLY) $(F90FLAGS) 
$(FCOMPILEONLY)$(OPTIONSEP)$$current_wd$(DIRSEP)$@ 
$$current_wd$(DIRSEP)$(basename $(notdir $<)).$(F90_SUFFIX)

From baiotti at ea.c.u-tokyo.ac.jp  Tue Nov 25 16:51:22 2008
From: baiotti at ea.c.u-tokyo.ac.jp (Baiotti Luca)
Date: Wed, 26 Nov 2008 07:51:22 +0900
Subject: [Developers] parfile-error warnings
In-Reply-To: <87109FFF-ECAF-436E-94A3-11197DB9F758@cct.lsu.edu>
References: <4915FDB6.5000402@ea.c.u-tokyo.ac.jp>
	<87109FFF-ECAF-436E-94A3-11197DB9F758@cct.lsu.edu>
Message-ID: <492C816A.3010001@ea.c.u-tokyo.ac.jp>

Erik Schnetter wrote:
> On Nov 8, 2008, at 14:59:34, Baiotti Luca wrote:
> 
>> Hello,
>>
>> warnings like:
>>
>> CCTKi_SetParameter: Error at line 11 in parameter file ....par while
>> activating thorns
>> WARNING level 0 in thorn Cactus processor 277 host qb540
>>  (line 93 of
>> /home/baiotti/Cactus/configs/whisky/build/Cactus/main/SetParams.c):
>>  ->WARNING level 0 in thorn Cactus processor 131 host ...
>>
>>
>> are printed by each processor. If all processors read the same parfile,
>> could Cactus print only one warning/error message instead of one per
>> processor?
> 
> The idea here (and in other, similar places) in Cactus is that warnings 
> generated by any processor are displayed on the root processor, since 
> warnings are important.
> 
> What you are probably looking for is a possibility to display a warning 
> only on the root processor.  One could implement this here quickly with 
> an if statement about the CCTK_WARN call.  A more general mechanism 
> would be more complex if it has to ensure that no warnings are lost.

Yes, I would like warnings that are identical on all processors to be 
displayed only once on the root processor. Or at least the warnings 
about parfile errors.

> Another annoying message is the very first message "setting warning 
> level to...", displayed 12288 times if running on that many processors.


Could some cactus developer implement these improvements?


Ciao,

Luca