From schnetter at cct.lsu.edu  Sun Apr  6 21:42:35 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sun, 6 Apr 2008 21:42:35 -0500
Subject: [Developers] [Patches] Problems with 4D grid arrays
In-Reply-To: <ECA01556-6F84-4711-AD4B-44B28C30629D@cct.lsu.edu>
References: <ECA01556-6F84-4711-AD4B-44B28C30629D@cct.lsu.edu>
Message-ID: <BD5F2103-D0EF-4FF3-909C-9FC507DB4031@cct.lsu.edu>

On Mar 19, 2008, at 20:48:09, Erik Schnetter wrote:
> Cactus has currently a problem if one uses grid arrays of dimension  
> D while grid functions have a dimension less than D.  During  
> initialisation, Cactus sets cctk_dim to the largest dimension of all  
> grid variables in all active thorns.  This is arguably wrong;  
> cctk_dim should be set to the (maximum) dimension of the grid  
> functions.
>
> The enclosed patch adds a new function to the flesh CCTK_MaxGFDim  
> which returns the (maximum) dimension of all grid functions.  This  
> function is used to set cctk_dim.


I applied this patch.

-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/20080406/9c5b488f/attachment.bin 

From schnetter at cct.lsu.edu  Sun Apr  6 23:16:07 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sun, 6 Apr 2008 23:16:07 -0500
Subject: [Developers] If clauses in schedule
Message-ID: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>

Schedule items in Cactus can have WHILE clauses, which means that they  
are executed while a certain condition are true.  I suggest to add IF  
clauses, which would mean that they are executed only if a certain  
condition is true.  The syntax is equivalent to WHILE clauses.

This is different from the existing if statements, which are only  
evaluated once at startup.  The new if clauses are evaluated every  
time the schedule is traversed.

-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.






--- StripMime Report -- processed MIME parts ---
multipart/mixed
  text/plain (text body -- kept)
  application/octet-stream
  text/plain (text body -- kept)
---

From hinder at gravity.psu.edu  Mon Apr  7 09:48:04 2008
From: hinder at gravity.psu.edu (Ian Hinder)
Date: Mon, 07 Apr 2008 10:48:04 -0400
Subject: [Developers] If clauses in schedule
In-Reply-To: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
Message-ID: <47FA3424.3080305@gravity.psu.edu>

Erik Schnetter wrote:
> Schedule items in Cactus can have WHILE clauses, which means that they  
> are executed while a certain condition are true.  I suggest to add IF  
> clauses, which would mean that they are executed only if a certain  
> condition is true.  The syntax is equivalent to WHILE clauses.
> 
> This is different from the existing if statements, which are only  
> evaluated once at startup.  The new if clauses are evaluated every  
> time the schedule is traversed.

Does this mean that the current implementation does not respect changes
to steerable parameters during a simulation, when those parameters are
used in if statements in schedule files?

Your suggestion sounds like a good idea - it brings up the question of
why it was not done like that before.  Was there a design decision that
the schedule tree should be static?

-- 
Ian Hinder
hinder at gravity.psu.edu
http://www.gravity.psu.edu/~hinder

From schnetter at cct.lsu.edu  Mon Apr  7 11:27:11 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 7 Apr 2008 11:27:11 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <47FA3424.3080305@gravity.psu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
	<47FA3424.3080305@gravity.psu.edu>
Message-ID: <C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>

On Apr 7, 2008, at 09:48:04, Ian Hinder wrote:
> Erik Schnetter wrote:
>> Schedule items in Cactus can have WHILE clauses, which means that  
>> they
>> are executed while a certain condition are true.  I suggest to add IF
>> clauses, which would mean that they are executed only if a certain
>> condition is true.  The syntax is equivalent to WHILE clauses.
>>
>> This is different from the existing if statements, which are only
>> evaluated once at startup.  The new if clauses are evaluated every
>> time the schedule is traversed.
>
> Does this mean that the current implementation does not respect  
> changes
> to steerable parameters during a simulation, when those parameters are
> used in if statements in schedule files?
>
> Your suggestion sounds like a good idea - it brings up the question of
> why it was not done like that before.  Was there a design decision  
> that
> the schedule tree should be static?


The schedule is calculated in the beginning.  It actually has to be  
calculated, since the dependencies have to be resolved and a correct  
order be determined.  The current if statements are evaluated once  
when the schedule is calculated.  This is used e.g. for choosing gauge  
conditions or evolution systems.

-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/20080407/50736e77/attachment.bin 

From hinder at gravity.psu.edu  Mon Apr  7 12:43:45 2008
From: hinder at gravity.psu.edu (Ian Hinder)
Date: Mon, 07 Apr 2008 13:43:45 -0400
Subject: [Developers] If clauses in schedule
In-Reply-To: <C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
Message-ID: <47FA5D51.1020403@gravity.psu.edu>

Erik Schnetter wrote:
> On Apr 7, 2008, at 09:48:04, Ian Hinder wrote:
>> Erik Schnetter wrote:
>>> Schedule items in Cactus can have WHILE clauses, which means that they
>>> are executed while a certain condition are true.  I suggest to add IF
>>> clauses, which would mean that they are executed only if a certain
>>> condition is true.  The syntax is equivalent to WHILE clauses.
>>>
>>> This is different from the existing if statements, which are only
>>> evaluated once at startup.  The new if clauses are evaluated every
>>> time the schedule is traversed.
>>
>> Does this mean that the current implementation does not respect changes
>> to steerable parameters during a simulation, when those parameters are
>> used in if statements in schedule files?
>>
>> Your suggestion sounds like a good idea - it brings up the question of
>> why it was not done like that before.  Was there a design decision that
>> the schedule tree should be static?
> 
> 
> The schedule is calculated in the beginning.  It actually has to be
> calculated, since the dependencies have to be resolved and a correct
> order be determined.  The current if statements are evaluated once when
> the schedule is calculated.  This is used e.g. for choosing gauge
> conditions or evolution systems.

OK - in that case I think your suggestion is a very good idea. For
example, I might want to change a gauge condition at some point in the
inspiral, and the easiest way to do this would be to steer a parameter.

Would the current syntax be extended to allow the statements to be
recalculated, which might have backward compatibility issues, or will
there be a new syntax?  Perhaps we could find out if there are any cases
that broke by extending the old syntax, and fix those, as it would be
very confusing to have two types of "if" in the schedule file.

-- 
Ian Hinder
hinder at gravity.psu.edu
http://www.gravity.psu.edu/~hinder

From schnetter at cct.lsu.edu  Mon Apr  7 12:47:29 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 7 Apr 2008 12:47:29 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <47FA5D51.1020403@gravity.psu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
Message-ID: <572553EE-F78E-4C41-8A93-18811245DF3A@cct.lsu.edu>

On Apr 7, 2008, at 12:43:45, Ian Hinder wrote:
> Erik Schnetter wrote:
>> On Apr 7, 2008, at 09:48:04, Ian Hinder wrote:
>>> Erik Schnetter wrote:
>>>> Schedule items in Cactus can have WHILE clauses, which means that  
>>>> they
>>>> are executed while a certain condition are true.  I suggest to  
>>>> add IF
>>>> clauses, which would mean that they are executed only if a certain
>>>> condition is true.  The syntax is equivalent to WHILE clauses.
>>>>
>>>> This is different from the existing if statements, which are only
>>>> evaluated once at startup.  The new if clauses are evaluated every
>>>> time the schedule is traversed.
>>>
>>> Does this mean that the current implementation does not respect  
>>> changes
>>> to steerable parameters during a simulation, when those parameters  
>>> are
>>> used in if statements in schedule files?
>>>
>>> Your suggestion sounds like a good idea - it brings up the  
>>> question of
>>> why it was not done like that before.  Was there a design decision  
>>> that
>>> the schedule tree should be static?
>>
>>
>> The schedule is calculated in the beginning.  It actually has to be
>> calculated, since the dependencies have to be resolved and a correct
>> order be determined.  The current if statements are evaluated once  
>> when
>> the schedule is calculated.  This is used e.g. for choosing gauge
>> conditions or evolution systems.
>
> OK - in that case I think your suggestion is a very good idea. For
> example, I might want to change a gauge condition at some point in the
> inspiral, and the easiest way to do this would be to steer a  
> parameter.
>
> Would the current syntax be extended to allow the statements to be
> recalculated, which might have backward compatibility issues, or will
> there be a new syntax?  Perhaps we could find out if there are any  
> cases
> that broke by extending the old syntax, and fix those, as it would be
> very confusing to have two types of "if" in the schedule file.


No, it is a new syntax.  The old syntax is

	if (condition) {
	  SCHEDULE ...
	  {
	    blah
	  }
	} /* end if */

The new syntax is the same as for WHILE conditions:

	SCHEDULE ... IF condition
	{
	  blah
	}

-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/20080407/952152fa/attachment.bin 

From frank.loeffler at aei.mpg.de  Mon Apr  7 12:56:57 2008
From: frank.loeffler at aei.mpg.de (Frank Loeffler)
Date: Mon, 7 Apr 2008 12:56:57 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <572553EE-F78E-4C41-8A93-18811245DF3A@cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
	<572553EE-F78E-4C41-8A93-18811245DF3A@cct.lsu.edu>
Message-ID: <20080407175644.GN29407@numrel07.cct.lsu.edu>

On Mon, Apr 07, 2008 at 12:47:29PM -0500, Erik Schnetter wrote:
> No, it is a new syntax.

I agree with Ian that we should investigate the possibility of having
only one if-syntax. Two would really be confusing.

Frank


From dprideout at gmail.com  Mon Apr  7 12:58:05 2008
From: dprideout at gmail.com (David Rideout)
Date: Mon, 7 Apr 2008 13:58:05 -0400
Subject: [Developers] If clauses in schedule
In-Reply-To: <572553EE-F78E-4C41-8A93-18811245DF3A@cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
	<572553EE-F78E-4C41-8A93-18811245DF3A@cct.lsu.edu>
Message-ID: <1ce81abb0804071058x3817676k48d0e067476f006a@mail.gmail.com>

Just to clarify, this could already be done with the WHILE option for
a schedule item, by defining a grid scalar and playing with its value
inside scheduled routines.  Erik is proposing a *much* simpler way to
implement (dynamic) if logic.

-David

On Mon, Apr 7, 2008 at 1:47 PM, Erik Schnetter <schnetter at cct.lsu.edu> wrote:
>
> On Apr 7, 2008, at 12:43:45, Ian Hinder wrote:
>
> > Erik Schnetter wrote:
> >
> > > On Apr 7, 2008, at 09:48:04, Ian Hinder wrote:
> > >
> > > > Erik Schnetter wrote:
> > > >
> > > > > Schedule items in Cactus can have WHILE clauses, which means that
> they
> > > > > are executed while a certain condition are true.  I suggest to add
> IF
> > > > > clauses, which would mean that they are executed only if a certain
> > > > > condition is true.  The syntax is equivalent to WHILE clauses.
> > > > >
> > > > > This is different from the existing if statements, which are only
> > > > > evaluated once at startup.  The new if clauses are evaluated every
> > > > > time the schedule is traversed.
> > > > >
> > > >
> > > > Does this mean that the current implementation does not respect
> changes
> > > > to steerable parameters during a simulation, when those parameters are
> > > > used in if statements in schedule files?
> > > >
> > > > Your suggestion sounds like a good idea - it brings up the question of
> > > > why it was not done like that before.  Was there a design decision
> that
> > > > the schedule tree should be static?
> > > >
> > >
> > >
> > > The schedule is calculated in the beginning.  It actually has to be
> > > calculated, since the dependencies have to be resolved and a correct
> > > order be determined.  The current if statements are evaluated once when
> > > the schedule is calculated.  This is used e.g. for choosing gauge
> > > conditions or evolution systems.
> > >
> >
> > OK - in that case I think your suggestion is a very good idea. For
> > example, I might want to change a gauge condition at some point in the
> > inspiral, and the easiest way to do this would be to steer a parameter.
> >
> > Would the current syntax be extended to allow the statements to be
> > recalculated, which might have backward compatibility issues, or will
> > there be a new syntax?  Perhaps we could find out if there are any cases
> > that broke by extending the old syntax, and fix those, as it would be
> > very confusing to have two types of "if" in the schedule file.
> >
>
>
>  No, it is a new syntax.  The old syntax is
>
>         if (condition) {
>           SCHEDULE ...
>           {
>             blah
>           }
>         } /* end if */
>
>  The new syntax is the same as for WHILE conditions:
>
>         SCHEDULE ... IF condition
>         {
>           blah
>
>
>         }
>
>  -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 schnetter at cct.lsu.edu  Mon Apr  7 13:21:19 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 7 Apr 2008 13:21:19 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <47FA5D51.1020403@gravity.psu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
Message-ID: <01E0052E-6C84-4279-AD95-3554196A76C3@cct.lsu.edu>

On Apr 7, 2008, at 12:43:45, Ian Hinder wrote:
> Would the current syntax be extended to allow the statements to be
> recalculated, which might have backward compatibility issues, or will
> there be a new syntax?  Perhaps we could find out if there are any  
> cases
> that broke by extending the old syntax, and fix those, as it would be
> very confusing to have two types of "if" in the schedule file.


It would be very difficult to combine both syntaxes.

The existing if statements are evaluated very early during a run and  
can only evaluate parameters, but can contain arbitrarily complex  
expressions since the expressions are transformed into C code.  In  
particular, they can also examine keyword and string parameters.

The new if clauses are evaluated at run time and can thus examine grid  
scalars.  Since there is no expression parser, they can only depend on  
whether a grid scalar is zero or not.  This is the same mechanism that  
is used for WHILE clauses.

-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/20080407/349c9ae2/attachment.bin 

From frank.loeffler at aei.mpg.de  Mon Apr  7 16:51:27 2008
From: frank.loeffler at aei.mpg.de (Frank Loeffler)
Date: Mon, 7 Apr 2008 16:51:27 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <01E0052E-6C84-4279-AD95-3554196A76C3@cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
	<01E0052E-6C84-4279-AD95-3554196A76C3@cct.lsu.edu>
Message-ID: <20080407215127.GO29407@numrel07.cct.lsu.edu>

On Mon, Apr 07, 2008 at 01:21:19PM -0500, Erik Schnetter wrote:
> The new if clauses are evaluated at run time and can thus examine grid 
> scalars.  Since there is no expression parser, they can only depend on 
> whether a grid scalar is zero or not.  This is the same mechanism that is 
> used for WHILE clauses.

What prevents Cactus from also translating those expressions to C and
executing them at runtime not only at the very beginning, but also
during the evolution?

Frank


From schnetter at cct.lsu.edu  Mon Apr  7 16:55:13 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 7 Apr 2008 16:55:13 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <20080407215127.GO29407@numrel07.cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
	<01E0052E-6C84-4279-AD95-3554196A76C3@cct.lsu.edu>
	<20080407215127.GO29407@numrel07.cct.lsu.edu>
Message-ID: <12AAB095-2C4B-45B1-9EE6-34AEBD18F541@cct.lsu.edu>

On Apr 7, 2008, at 16:51:27, Frank Loeffler wrote:
> On Mon, Apr 07, 2008 at 01:21:19PM -0500, Erik Schnetter wrote:
>> The new if clauses are evaluated at run time and can thus examine  
>> grid
>> scalars.  Since there is no expression parser, they can only depend  
>> on
>> whether a grid scalar is zero or not.  This is the same mechanism  
>> that is
>> used for WHILE clauses.
>
> What prevents Cactus from also translating those expressions to C and
> executing them at runtime not only at the very beginning, but also
> during the evolution?


In principle nothing.  One would need to come up with a good syntax,  
ensure that the translation happens correctly, and then implement  
this.  Would this feature be important to you?

-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/20080407/c6390552/attachment.bin 

From frank.loeffler at aei.mpg.de  Mon Apr  7 17:10:16 2008
From: frank.loeffler at aei.mpg.de (Frank Loeffler)
Date: Mon, 7 Apr 2008 17:10:16 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <12AAB095-2C4B-45B1-9EE6-34AEBD18F541@cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
	<01E0052E-6C84-4279-AD95-3554196A76C3@cct.lsu.edu>
	<20080407215127.GO29407@numrel07.cct.lsu.edu>
	<12AAB095-2C4B-45B1-9EE6-34AEBD18F541@cct.lsu.edu>
Message-ID: <20080407221016.GA30252@numrel07.cct.lsu.edu>

On Mon, Apr 07, 2008 at 04:55:13PM -0500, Erik Schnetter wrote:
> In principle nothing.  One would need to come up with a good syntax, ensure 
> that the translation happens correctly, and then implement this.  Would 
> this feature be important to you?

I understood that some form of this translation is already implemented
for the while syntax. I assumed it would be easy to do the same for the
if statement as well.
It is not particularly interesting for me, but I feel that introducing
two different if statements could cause lots of confusion in the future.
Thus I thought instead of introducing a second 'if' statement we could
extend the current one such that it fulfilles the request. I could not
imagine lots of cases where the old behaviour would be changed by that
except by mistake anyway. And if there are really a few of those cases,
it might be worth adjusting them if we could avoid two different if
statements in the future.

Frank


From schnetter at cct.lsu.edu  Tue Apr  8 10:20:56 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 8 Apr 2008 10:20:56 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <20080407221016.GA30252@numrel07.cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
	<01E0052E-6C84-4279-AD95-3554196A76C3@cct.lsu.edu>
	<20080407215127.GO29407@numrel07.cct.lsu.edu>
	<12AAB095-2C4B-45B1-9EE6-34AEBD18F541@cct.lsu.edu>
	<20080407221016.GA30252@numrel07.cct.lsu.edu>
Message-ID: <636FB86A-DFE5-46AA-9104-8C33C8EF13E7@cct.lsu.edu>


On Apr 7, 2008, at 17:10:16, Frank Loeffler wrote:
> On Mon, Apr 07, 2008 at 04:55:13PM -0500, Erik Schnetter wrote:
>> In principle nothing.  One would need to come up with a good  
>> syntax, ensure
>> that the translation happens correctly, and then implement this.   
>> Would
>> this feature be important to you?
>
> I understood that some form of this translation is already implemented
> for the while syntax. I assumed it would be easy to do the same for  
> the
> if statement as well.
> It is not particularly interesting for me, but I feel that introducing
> two different if statements could cause lots of confusion in the  
> future.
> Thus I thought instead of introducing a second 'if' statement we could
> extend the current one such that it fulfilles the request. I could not
> imagine lots of cases where the old behaviour would be changed by that
> except by mistake anyway. And if there are really a few of those  
> cases,
> it might be worth adjusting them if we could avoid two different if
> statements in the future.


The two cases are actually quite different.  If you evaluate an if  
statement before constructing a schedule, then you can have  
descriptions like:

if (forward) {
   schedule A before B
} else {
   schedule B before A
}

This is not possible with if clauses evaluated at run time, since  
these only switch on and off parts of a schedule.  In particular, the  
conditions "A before B" and "B before A" are contradictory.  By  
evaluating the if statement before actually constructing the schedule,  
this inconsistency is avoided.

The new if clauses do not affect the order in which scheduled items  
are executed.  The schedule is constant in time, but certain elements  
are skipped depending on certain conditions.  A schedule description

   schedule A if condX

becomes internally at run time something like

   if condX execute A

similar to the existing

   while condY execute B

-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/20080408/9145c999/attachment-0001.bin 

From frank.loeffler at aei.mpg.de  Tue Apr  8 10:34:55 2008
From: frank.loeffler at aei.mpg.de (Frank Loeffler)
Date: Tue, 8 Apr 2008 10:34:55 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <636FB86A-DFE5-46AA-9104-8C33C8EF13E7@cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
	<01E0052E-6C84-4279-AD95-3554196A76C3@cct.lsu.edu>
	<20080407215127.GO29407@numrel07.cct.lsu.edu>
	<12AAB095-2C4B-45B1-9EE6-34AEBD18F541@cct.lsu.edu>
	<20080407221016.GA30252@numrel07.cct.lsu.edu>
	<636FB86A-DFE5-46AA-9104-8C33C8EF13E7@cct.lsu.edu>
Message-ID: <20080408153454.GP30252@numrel07.cct.lsu.edu>

On Tue, Apr 08, 2008 at 10:20:56AM -0500, Erik Schnetter wrote:
> The new if clauses do not affect the order in which scheduled items are 
> executed.  The schedule is constant in time, but certain elements are 
> skipped depending on certain conditions.  A schedule description

Thanks, I now understand that the new 'if' cannot possibly do all the
things the old one can and vice versa. So, I now support your proposal.
Also the syntax now makes more sense for me.

Frank


From dprideout at gmail.com  Tue Apr  8 10:39:07 2008
From: dprideout at gmail.com (David Rideout)
Date: Tue, 8 Apr 2008 11:39:07 -0400
Subject: [Developers] If clauses in schedule
In-Reply-To: <636FB86A-DFE5-46AA-9104-8C33C8EF13E7@cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
	<01E0052E-6C84-4279-AD95-3554196A76C3@cct.lsu.edu>
	<20080407215127.GO29407@numrel07.cct.lsu.edu>
	<12AAB095-2C4B-45B1-9EE6-34AEBD18F541@cct.lsu.edu>
	<20080407221016.GA30252@numrel07.cct.lsu.edu>
	<636FB86A-DFE5-46AA-9104-8C33C8EF13E7@cct.lsu.edu>
Message-ID: <1ce81abb0804080839o5d03421dyfac4a603066cdf81@mail.gmail.com>

What sort of expression can we put for condX?  Just an integer grid
scalar?  A parameter?  I recall you mentioned that there is no
expression parsing for this.  If it is just an integer grid scalar,
then is this sufficiently different from the while syntax to justify
its addition?

-David

On Tue, Apr 8, 2008 at 11:20 AM, Erik Schnetter <schnetter at cct.lsu.edu> wrote:

>  The new if clauses do not affect the order in which scheduled items are
> executed.  The schedule is constant in time, but certain elements are
> skipped depending on certain conditions.  A schedule description
>
>   schedule A if condX
>
>  becomes internally at run time something like
>
>   if condX execute A
>
>  similar to the existing
>
>   while condY execute B
>
>
>
>  -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 schnetter at cct.lsu.edu  Tue Apr  8 11:46:45 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 8 Apr 2008 11:46:45 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <1ce81abb0804080839o5d03421dyfac4a603066cdf81@mail.gmail.com>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
	<47FA3424.3080305@gravity.psu.edu>
	<C62EF4AE-2601-4B0C-A60B-44142BED311A@cct.lsu.edu>
	<47FA5D51.1020403@gravity.psu.edu>
	<01E0052E-6C84-4279-AD95-3554196A76C3@cct.lsu.edu>
	<20080407215127.GO29407@numrel07.cct.lsu.edu>
	<12AAB095-2C4B-45B1-9EE6-34AEBD18F541@cct.lsu.edu>
	<20080407221016.GA30252@numrel07.cct.lsu.edu>
	<636FB86A-DFE5-46AA-9104-8C33C8EF13E7@cct.lsu.edu>
	<1ce81abb0804080839o5d03421dyfac4a603066cdf81@mail.gmail.com>
Message-ID: <78143294-1912-40F8-9A47-E781E2B244DF@cct.lsu.edu>

The condition has to be calculated ahead of time and stored into a  
grid scalar.

Yes, an if clause is sufficiently different from a while condition to  
justify its addition.

-erik

On Apr 8, 2008, at 10:39:07, David Rideout wrote:
> What sort of expression can we put for condX?  Just an integer grid
> scalar?  A parameter?  I recall you mentioned that there is no
> expression parsing for this.  If it is just an integer grid scalar,
> then is this sufficiently different from the while syntax to justify
> its addition?
>
> -David
>
> On Tue, Apr 8, 2008 at 11:20 AM, Erik Schnetter  
> <schnetter at cct.lsu.edu> wrote:
>
>> The new if clauses do not affect the order in which scheduled items  
>> are
>> executed.  The schedule is constant in time, but certain elements are
>> skipped depending on certain conditions.  A schedule description
>>
>>  schedule A if condX
>>
>> becomes internally at run time something like
>>
>>  if condX execute A
>>
>> similar to the existing
>>
>>  while condY execute B
>>
>>
>>
>> -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
>>
>>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>


-- 
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/20080408/05eb3a24/attachment.bin 

From schnetter at cct.lsu.edu  Tue Apr  8 23:19:50 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 8 Apr 2008 23:19:50 -0500
Subject: [Developers] If clauses in schedule
In-Reply-To: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
References: <5AE220A5-2FF9-4082-AF8D-FBB01C34433A@cct.lsu.edu>
Message-ID: <ECC89846-7A6D-4F10-ACF5-83D3A4DE8740@cct.lsu.edu>

On Apr 6, 2008, at 23:16:07, Erik Schnetter wrote:
> Schedule items in Cactus can have WHILE clauses, which means that they
> are executed while a certain condition are true.  I suggest to add IF
> clauses, which would mean that they are executed only if a certain
> condition is true.  The syntax is equivalent to WHILE clauses.
>
> This is different from the existing if statements, which are only
> evaluated once at startup.  The new if clauses are evaluated every
> time the schedule is traversed.


I have committed this patch.

-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/20080408/8fe5544c/attachment.bin 

From schnetter at cct.lsu.edu  Wed Apr  9 23:33:08 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 9 Apr 2008 23:33:08 -0500
Subject: [Developers] Storing gauge time derivatives in ADMBase
Message-ID: <7187E9BE-6642-40DE-A0CE-04BCE5A98C9A@cct.lsu.edu>

The ADMBase variables store currently the 3-metric, lapse, shift, and  
extrinsic curvature.  They do not store the time derivatives of lapse  
and shift, which makes it impossible to calculate the time derivative  
of the 4-metric from the ADMBase variables.  This is a shortcoming,  
since almost all current evolution systems require these, including  
common BSSN gauge conditions and harmonic evolution schemes.  (In many  
cases, initial data assume that these additional time derivatives are  
zero to get around this issue.)

The enclosed patch adds grid functions for dtlapse and dtbetax,  
dtbetay, and dtbetaz.  It also adds a few state variables so that  
codes can determine whether these variables have storage; storage is  
off by default for backwards compatibility.  This is similar to the  
shift vector, which also has no storage by default.

-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.






--- StripMime Report -- processed MIME parts ---
multipart/mixed
  text/plain (text body -- kept)
  application/octet-stream
  text/plain (text body -- kept)
---

From schnetter at cct.lsu.edu  Tue Apr 15 14:39:45 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 15 Apr 2008 14:39:45 -0500
Subject: [Developers] [Patches] Storing gauge time derivatives in ADMBase
In-Reply-To: <7187E9BE-6642-40DE-A0CE-04BCE5A98C9A@cct.lsu.edu>
References: <7187E9BE-6642-40DE-A0CE-04BCE5A98C9A@cct.lsu.edu>
Message-ID: <A0D100DB-6DD3-4066-8256-C5E8EF84246E@cct.lsu.edu>

On Apr 9, 2008, at 23:33:08, Erik Schnetter wrote:
> The ADMBase variables store currently the 3-metric, lapse, shift,  
> and extrinsic curvature.  They do not store the time derivatives of  
> lapse and shift, which makes it impossible to calculate the time  
> derivative of the 4-metric from the ADMBase variables.  This is a  
> shortcoming, since almost all current evolution systems require  
> these, including common BSSN gauge conditions and harmonic evolution  
> schemes.  (In many cases, initial data assume that these additional  
> time derivatives are zero to get around this issue.)
>
> The enclosed patch adds grid functions for dtlapse and dtbetax,  
> dtbetay, and dtbetaz.  It also adds a few state variables so that  
> codes can determine whether these variables have storage; storage is  
> off by default for backwards compatibility.  This is similar to the  
> shift vector, which also has no storage by default.


I have applied this patch.

-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.




From schnetter at cct.lsu.edu  Wed Apr 16 12:37:22 2008
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 16 Apr 2008 12:37:22 -0500
Subject: [Developers] patch to add ch_mx (Myrinet Express) as an
	MPICH_DEVICE
In-Reply-To: <Pine.LNX.4.64.0705171143200.17352@fandango.dyndns.org>
References: <20070511110537.08y7e6j9ggogc4ko@webmail.cct.lsu.edu>
	<0B10C0EF-8BA8-4C87-AB7F-D2533F88D7E2@cct.lsu.edu>
	<464C246B.5010809@aei.mpg.de>
	<Pine.LNX.4.64.0705171143200.17352@fandango.dyndns.org>
Message-ID: <A4300269-3565-411D-9277-F974109605AA@cct.lsu.edu>

On May 17, 2007, at 05:43:47, Tom Goodale wrote:
> On Thu, 17 May 2007, Thomas Radke wrote:
>
>> Erik Schnetter wrote:
>>> On May 11, 2007, at 11:05:37, jtao at cct.lsu.edu wrote:
>>>
>>>> A case branch added in Cactus/lib/make/extras/MPI/MPICH to support
>>>> Myrinet Express (ch_mx).
>>>>
>>>> Notice that I still use MYRINET_DIR to indicate the ch_mx dir.
>>>>
>>>> Document will be added to the user guide after the patch is  
>>>> applied.
>>>
>>>
>>> I think the patch looks fine.
>>
>> I think so too.
>
> Ok, go ahead and commit then.


Is this proposed patch still relevant?  Should it be committed?

-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/20080416/f8671b9e/attachment.bin 

From tradke at aei.mpg.de  Thu Apr 17 04:02:46 2008
From: tradke at aei.mpg.de (Thomas Radke)
Date: Thu, 17 Apr 2008 11:02:46 +0200
Subject: [Developers] patch to add ch_mx (Myrinet Express) as
	an	MPICH_DEVICE
In-Reply-To: <A4300269-3565-411D-9277-F974109605AA@cct.lsu.edu>
References: <20070511110537.08y7e6j9ggogc4ko@webmail.cct.lsu.edu>	<0B10C0EF-8BA8-4C87-AB7F-D2533F88D7E2@cct.lsu.edu>	<464C246B.5010809@aei.mpg.de>	<Pine.LNX.4.64.0705171143200.17352@fandango.dyndns.org>
	<A4300269-3565-411D-9277-F974109605AA@cct.lsu.edu>
Message-ID: <48071236.6060807@aei.mpg.de>

Erik Schnetter wrote:
> On May 17, 2007, at 05:43:47, Tom Goodale wrote:
> 
>> On Thu, 17 May 2007, Thomas Radke wrote:
>>
>>> Erik Schnetter wrote:
>>>
>>>> On May 11, 2007, at 11:05:37, jtao at cct.lsu.edu wrote:
>>>>
>>>>> A case branch added in Cactus/lib/make/extras/MPI/MPICH to support
>>>>> Myrinet Express (ch_mx).
>>>>>
>>>>> Notice that I still use MYRINET_DIR to indicate the ch_mx dir.
>>>>>
>>>>> Document will be added to the user guide after the patch is  applied.
>>>>
>>>>
>>>>
>>>> I think the patch looks fine.
>>>
>>>
>>> I think so too.
>>
>>
>> Ok, go ahead and commit then.
> 
> 
> 
> Is this proposed patch still relevant?  Should it be committed?

I wouldn't know any Myrinet cluster where I still have an account.
Anyway, the patch looks good to me, it wouldn't hurt to commit it.

-- 
Cheers, Thomas.