From szilagyi at aei.mpg.de  Wed May  2 14:42:43 2007
From: szilagyi at aei.mpg.de (Bela Szilagyi)
Date: Wed, 2 May 2007 21:42:43 +0200
Subject: [Developers] can we make the ADMAnalysis GF's public?
Message-ID: <200705022142.43626.szilagyi@aei.mpg.de>

I'd like to use quantites computed in ADMAnalysis without too many tricks such 
as flesh calls for pointers to GFs or flesh calls for storage for GFs that 
are private to some other thorn.

Hence the question -- can we make the ADMAnalysis GF's public?

This is already done for the ADMConstraints ...



-- 
Bela Szilagyi
----------------------------------------------------
Max-Planck-Institut f?r Gravitationsphysik
Albert-Einstein-Institut
Tel: +49 331 567 7189
Fax: +49 331 567 7252
----------------------------------------------------



From schnetter at cct.lsu.edu  Wed May  2 14:45:11 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 2 May 2007 14:45:11 -0500
Subject: [Developers] can we make the ADMAnalysis GF's public?
In-Reply-To: <200705022142.43626.szilagyi@aei.mpg.de>
References: <200705022142.43626.szilagyi@aei.mpg.de>
Message-ID: <D2980118-C262-4932-B98F-2207D0CA2165@cct.lsu.edu>

On May 2, 2007, at 14:42:43, Bela Szilagyi wrote:

> I'd like to use quantites computed in ADMAnalysis without too many  
> tricks such
> as flesh calls for pointers to GFs or flesh calls for storage for  
> GFs that
> are private to some other thorn.
>
> Hence the question -- can we make the ADMAnalysis GF's public?
>
> This is already done for the ADMConstraints ...

Yes, we can do that.

If you use these quantities, you need to make sure that (a) these  
variables have storage even when the thorn is not active, and (b)  
that they are calculated before you use them.  This can all be done  
in the schedule.ccl of the thorn that uses these variables.

-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/developers/attachments/20070502/d1c60662/attachment.bin 

From szilagyi at aei.mpg.de  Wed May  2 14:53:47 2007
From: szilagyi at aei.mpg.de (Bela Szilagyi)
Date: Wed, 2 May 2007 21:53:47 +0200
Subject: [Developers] can we make the ADMAnalysis GF's public?
In-Reply-To: <D2980118-C262-4932-B98F-2207D0CA2165@cct.lsu.edu>
References: <200705022142.43626.szilagyi@aei.mpg.de>
	<D2980118-C262-4932-B98F-2207D0CA2165@cct.lsu.edu>
Message-ID: <200705022153.47078.szilagyi@aei.mpg.de>

Yes, I see the scheduling groups for the things I need.


On Wednesday 02 May 2007 21:45, Erik Schnetter wrote:
> On May 2, 2007, at 14:42:43, Bela Szilagyi wrote:
> > I'd like to use quantites computed in ADMAnalysis without too many
> > tricks such
> > as flesh calls for pointers to GFs or flesh calls for storage for
> > GFs that
> > are private to some other thorn.
> >
> > Hence the question -- can we make the ADMAnalysis GF's public?
> >
> > This is already done for the ADMConstraints ...
>
> Yes, we can do that.
>
> If you use these quantities, you need to make sure that (a) these
> variables have storage even when the thorn is not active, and (b)
> that they are calculated before you use them.  This can all be done
> in the schedule.ccl of the thorn that uses these variables.
>
> -erik

-- 
Bela Szilagyi
----------------------------------------------------
Max-Planck-Institut f?r Gravitationsphysik
Albert-Einstein-Institut
Tel: +49 331 567 7189
Fax: +49 331 567 7252
----------------------------------------------------



From jtao at cct.lsu.edu  Fri May 11 08:50:03 2007
From: jtao at cct.lsu.edu (jtao at cct.lsu.edu)
Date: Fri, 11 May 2007 08:50:03 -0500
Subject: [Developers] adding ch_mx (Myrinet Express) as an MPICH_DEVICE ?
Message-ID: <20070511085003.x1be0d1t6ogkwwcw@webmail.cct.lsu.edu>

Recently, I got access to a local Opteron(4 Opteron 875, 16GB in
each node) cluster connected via Myrinet Express and did some
benchmark runs. Using MPI=CUSTOM is actually pretty straightforward
but it will be nice to have ch_mx as an MPICH_DEVICE if it hasn't
been considered.

Regards,
Jian


From schnetter at cct.lsu.edu  Fri May 11 09:55:19 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Fri, 11 May 2007 09:55:19 -0500
Subject: [Developers] adding ch_mx (Myrinet Express) as an MPICH_DEVICE ?
In-Reply-To: <20070511085003.x1be0d1t6ogkwwcw@webmail.cct.lsu.edu>
References: <20070511085003.x1be0d1t6ogkwwcw@webmail.cct.lsu.edu>
Message-ID: <9374D923-4A1D-4D97-B303-DB25BD54BFBE@cct.lsu.edu>

On May 11, 2007, at 08:50:03, jtao at cct.lsu.edu wrote:

> Recently, I got access to a local Opteron(4 Opteron 875, 16GB in
> each node) cluster connected via Myrinet Express and did some
> benchmark runs. Using MPI=CUSTOM is actually pretty straightforward
> but it will be nice to have ch_mx as an MPICH_DEVICE if it hasn't
> been considered.

If it is not in the source already, then it is likely that no one has  
done it yet.  Do you want to send a patch?  What is the speedup  
compared to the standard device?

-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/developers/attachments/20070511/dab1e75f/attachment.bin 

From jtao at cct.lsu.edu  Fri May 11 11:05:37 2007
From: jtao at cct.lsu.edu (jtao at cct.lsu.edu)
Date: Fri, 11 May 2007 11:05:37 -0500
Subject: [Developers] patch to add ch_mx (Myrinet Express) as an MPICH_DEVICE
Message-ID: <20070511110537.08y7e6j9ggogc4ko@webmail.cct.lsu.edu>

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.

Regards,
Jian


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

From schnetter at cct.lsu.edu  Wed May 16 16:22:56 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 16 May 2007 16:22:56 -0500
Subject: [Developers] Fwd: [CactusMaint] CactusUtils/2079: Patch for
	thorn TimerReport: Output timer reports to a file instead of
	to stdout
In-Reply-To: <90E0CFE4-3E58-48F9-BC36-8BEB16B42F85@cct.lsu.edu>
References: <A1038CDF-FAAE-4F6D-9E2C-296EFF6916D1@cct.lsu.edu>
	<90E0CFE4-3E58-48F9-BC36-8BEB16B42F85@cct.lsu.edu>
Message-ID: <05755B8B-4C39-4997-AC02-C03AC9CA2407@cct.lsu.edu>

The message below proposes a patch to the flesh.  Thomas, Jonathan,  
Tom, could you have a look?

Thanks,
-erik

On Apr 28, 2007, at 17:33:15, Erik Schnetter wrote:

> Begin forwarded message:
>
>> From: Erik Schnetter <schnetter at cct.lsu.edu>
>> Date: April 28, 2007 5:04:16 PM CDT
>> To: Cactus Maintainers <cactusmaint at cactuscode.org>,  
>> bugs at cactuscode.org, Tom Goodale <goodale at cct.lsu.edu>, gnats- 
>> admin at cactuscode.org
>> Subject: Re: [CactusMaint] CactusUtils/2079: Patch for thorn  
>> TimerReport: Output timer reports to a file instead of to stdout
>> Reply-To: CactusMaint <cactusmaint at cactuscode.org>
>>
>> http://www.cactuscode.org/cactus_cgi-bin/gnatsweb.pl?cmd=view% 
>> 20audit-trail&database=cactus&pr=2079
>>
>> I have added a patch that implements a new flesh function  
>> CCTK_SchedulePrintTimesToFile.  The internal schedule printing  
>> functions take an additional FILE* argument, and the existing  
>> CCTK_SchedulePrintTimes prints to stdout.
>>
>> -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.
>>
>>
>>
>> _______________________________________________
>> CactusMaint site list
>> CactusMaint at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/cactusmaint
>
>
> -- 
> 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.
>
>
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers


-- 
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/developers/attachments/20070516/6b9b1eca/attachment.bin 

From schnetter at cct.lsu.edu  Wed May 16 18:52:06 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 16 May 2007 18:52:06 -0500
Subject: [Developers] patch to add ch_mx (Myrinet Express) as an
	MPICH_DEVICE
In-Reply-To: <20070511110537.08y7e6j9ggogc4ko@webmail.cct.lsu.edu>
References: <20070511110537.08y7e6j9ggogc4ko@webmail.cct.lsu.edu>
Message-ID: <0B10C0EF-8BA8-4C87-AB7F-D2533F88D7E2@cct.lsu.edu>

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.

-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/developers/attachments/20070516/e82783f9/attachment-0001.bin 

From tradke at aei.mpg.de  Thu May 17 04:46:19 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Thu, 17 May 2007 11:46:19 +0200
Subject: [Developers] patch to add ch_mx (Myrinet Express) as
	an	MPICH_DEVICE
In-Reply-To: <0B10C0EF-8BA8-4C87-AB7F-D2533F88D7E2@cct.lsu.edu>
References: <20070511110537.08y7e6j9ggogc4ko@webmail.cct.lsu.edu>
	<0B10C0EF-8BA8-4C87-AB7F-D2533F88D7E2@cct.lsu.edu>
Message-ID: <464C246B.5010809@aei.mpg.de>

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.

-- 
Cheers, Thomas.

From goodale at cct.lsu.edu  Thu May 17 05:43:47 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Thu, 17 May 2007 11:43:47 +0100 (BST)
Subject: [Developers] patch to add ch_mx (Myrinet Express) as an
	MPICH_DEVICE
In-Reply-To: <464C246B.5010809@aei.mpg.de>
References: <20070511110537.08y7e6j9ggogc4ko@webmail.cct.lsu.edu>
	<0B10C0EF-8BA8-4C87-AB7F-D2533F88D7E2@cct.lsu.edu>
	<464C246B.5010809@aei.mpg.de>
Message-ID: <Pine.LNX.4.64.0705171143200.17352@fandango.dyndns.org>

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.

Cheers,

Tom

From tradke at aei.mpg.de  Thu May 17 06:00:58 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Thu, 17 May 2007 13:00:58 +0200
Subject: [Developers] Fwd: [CactusMaint] CactusUtils/2079: Patch
 for	thorn TimerReport: Output timer reports to a file instead of	to stdout
In-Reply-To: <05755B8B-4C39-4997-AC02-C03AC9CA2407@cct.lsu.edu>
References: <A1038CDF-FAAE-4F6D-9E2C-296EFF6916D1@cct.lsu.edu>	<90E0CFE4-3E58-48F9-BC36-8BEB16B42F85@cct.lsu.edu>
	<05755B8B-4C39-4997-AC02-C03AC9CA2407@cct.lsu.edu>
Message-ID: <464C35EA.60603@aei.mpg.de>

Erik Schnetter wrote:
> The message below proposes a patch to the flesh.  Thomas, Jonathan,  
> Tom, could you have a look?

With this new flesh function CCTK_SchedulePrintTimesToFile() your patch 
to thorn TimerReport becomes partially obsolete, I presume. I have added 
a new patch (attachement 2 on 
http://www.cactuscode.org/cactus_cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=cactus&pr=2079) 
which should replace the old one. Two comments to this one:

  * In schedule.ccl the TimerReport_Output routine at TERMINATE must be
    scheduled BEFORE DriverTerminate, otherwise you will run into a
    'null communicator' MPI error when calling 'CCTK_MyProc(cctkGH)'.
    This slight rescheduling of routines implies that we can't measure
    the exact time spent in the TERMINATE bin but the inaccuracy should
    be negligible.

  * Declaring a large local array 'char filename [10000];' in Output.c
    is potentially dangerous and probably overkill anyway. I reduced
    its size to 200 characters which should suffice.

I have tested your flesh patch with the most recent TimerReport patch, 
and they work fine for me.

-- 
Cheers, Thomas.

From schnetter at cct.lsu.edu  Thu May 17 12:45:33 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Thu, 17 May 2007 12:45:33 -0500
Subject: [Developers] Fwd: [CactusMaint] CactusUtils/2079: Patch
	for	thorn TimerReport: Output timer reports to a file instead
	of	to stdout
In-Reply-To: <464C35EA.60603@aei.mpg.de>
References: <A1038CDF-FAAE-4F6D-9E2C-296EFF6916D1@cct.lsu.edu>	<90E0CFE4-3E58-48F9-BC36-8BEB16B42F85@cct.lsu.edu>
	<05755B8B-4C39-4997-AC02-C03AC9CA2407@cct.lsu.edu>
	<464C35EA.60603@aei.mpg.de>
Message-ID: <9D9A51E9-2EB2-40DC-95DC-46114B76FECC@cct.lsu.edu>

On May 17, 2007, at 06:00:58, Thomas Radke wrote:

> Erik Schnetter wrote:
>> The message below proposes a patch to the flesh.  Thomas, Jonathan,
>> Tom, could you have a look?
>
> With this new flesh function CCTK_SchedulePrintTimesToFile() your  
> patch
> to thorn TimerReport becomes partially obsolete, I presume. I have  
> added
> a new patch (attachement 2 on
> http://www.cactuscode.org/cactus_cgi-bin/gnatsweb.pl?cmd=view% 
> 20audit-trail&database=cactus&pr=2079)
> which should replace the old one. Two comments to this one:
>
>   * In schedule.ccl the TimerReport_Output routine at TERMINATE  
> must be
>     scheduled BEFORE DriverTerminate, otherwise you will run into a
>     'null communicator' MPI error when calling 'CCTK_MyProc(cctkGH)'.
>     This slight rescheduling of routines implies that we can't measure
>     the exact time spent in the TERMINATE bin but the inaccuracy  
> should
>     be negligible.
>
>   * Declaring a large local array 'char filename [10000];' in Output.c
>     is potentially dangerous and probably overkill anyway. I reduced
>     its size to 200 characters which should suffice.

I think Posix specifies that files names can be up to 1023 characters  
long.  What if a file name is longer, e.g. because it contains a  
URL?  File names can easily be longer than 80 characters, so a hard  
limit of 200 is dangerously close.

Why do you think that 10000 is dangerous?  This space will be  
allocated on the stack for a brief time.  Do you think that the stack  
cannot handle this?  BSSN_MoL has so many local variables that it  
requires much more stack space, or the compiler has to allocate the  
variables somewhere else (which may happen).  Is there a machine  
where stack space is an issue?

I don't agree with a limit of 200.  I think the limit needs to be  
either very large, or I will replace it by an automatic allocation,  
although this complicates the code.

-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/developers/attachments/20070517/79b106b3/attachment.bin 

From tradke at aei.mpg.de  Fri May 18 03:29:41 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Fri, 18 May 2007 10:29:41 +0200
Subject: [Developers] Fwd: [CactusMaint] CactusUtils/2079:
 Patch	for	thorn TimerReport: Output timer reports to a file instead	of	to
 stdout
In-Reply-To: <9D9A51E9-2EB2-40DC-95DC-46114B76FECC@cct.lsu.edu>
References: <A1038CDF-FAAE-4F6D-9E2C-296EFF6916D1@cct.lsu.edu>	<90E0CFE4-3E58-48F9-BC36-8BEB16B42F85@cct.lsu.edu>	<05755B8B-4C39-4997-AC02-C03AC9CA2407@cct.lsu.edu>	<464C35EA.60603@aei.mpg.de>
	<9D9A51E9-2EB2-40DC-95DC-46114B76FECC@cct.lsu.edu>
Message-ID: <464D63F5.20609@aei.mpg.de>

Erik Schnetter wrote:
>>   * Declaring a large local array 'char filename [10000];' in Output.c
>>     is potentially dangerous and probably overkill anyway. I reduced
>>     its size to 200 characters which should suffice.
> 
> 
> I think Posix specifies that files names can be up to 1023 characters  
> long.  What if a file name is longer, e.g. because it contains a  URL?  
> File names can easily be longer than 80 characters, so a hard  limit of 
> 200 is dangerously close.

This is true.

> Why do you think that 10000 is dangerous?  This space will be  allocated 
> on the stack for a brief time.  Do you think that the stack  cannot 
> handle this?  BSSN_MoL has so many local variables that it  requires 
> much more stack space, or the compiler has to allocate the  variables 
> somewhere else (which may happen).  Is there a machine  where stack 
> space is an issue?
> 
> I don't agree with a limit of 200.  I think the limit needs to be  
> either very large, or I will replace it by an automatic allocation,  
> although this complicates the code.

Yes, I would see the potential danger of stack overflow. Not necessarily 
in this function, agreed, as there is only one such array definition.
Still I'd rather implement it as an explicit array allocation even 
though it would slightly complicate the code.
Many trivial things, such as building a filename from some components, 
could be implemented so much more elegant with C++ strings. We should 
allow ourselfs to use standard C++ features more often also for Cactus 
infrastructure thorns.

-- 
Cheers, Thomas.

From schnetter at cct.lsu.edu  Fri May 18 06:38:42 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Fri, 18 May 2007 06:38:42 -0500
Subject: [Developers] Fwd: [CactusMaint] CactusUtils/2079:
	Patch	for	thorn TimerReport: Output timer reports to a file
	instead	of	to stdout
In-Reply-To: <464D63F5.20609@aei.mpg.de>
References: <A1038CDF-FAAE-4F6D-9E2C-296EFF6916D1@cct.lsu.edu>	<90E0CFE4-3E58-48F9-BC36-8BEB16B42F85@cct.lsu.edu>	<05755B8B-4C39-4997-AC02-C03AC9CA2407@cct.lsu.edu>	<464C35EA.60603@aei.mpg.de>
	<9D9A51E9-2EB2-40DC-95DC-46114B76FECC@cct.lsu.edu>
	<464D63F5.20609@aei.mpg.de>
Message-ID: <5157EDA4-E7D0-4187-B92C-C6B499D14D6F@cct.lsu.edu>

On May 18, 2007, at 03:29:41, Thomas Radke wrote:

> Many trivial things, such as building a filename from some components,
> could be implemented so much more elegant with C++ strings. We should
> allow ourselfs to use standard C++ features more often also for Cactus
> infrastructure thorns.

Yes, we definitively should.

Why don't we start with this thorn?  It is not crucial, so it would  
make a nice test balloon.

-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/developers/attachments/20070518/3e6c5ee2/attachment.bin 

From schnetter at cct.lsu.edu  Sun May 20 11:58:26 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sun, 20 May 2007 11:58:26 -0500
Subject: [Developers] Problems with make -j
Message-ID: <B1B51298-A451-4886-8083-186EECF89E15@cct.lsu.edu>

Sometimes when I build a Cactus configuration with "make -j4", the "- 
j4" option is ignored, and make builds sequentially.  I think this  
occurs mostly when the CST stage needs to run.

Has anybody observed this as well?  Do you know what the cause could be?

Maybe related is the fact that, when configuring, Cactus picks up the  
options "-fds 3,4", which are used by make to communicate between sub- 
makes to ensure that no more than 4 processes are running at the same  
time.  Could this maybe confuse make?

-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/developers/attachments/20070520/aff3a653/attachment.bin 

From frank.loeffler at aei.mpg.de  Mon May 21 02:32:02 2007
From: frank.loeffler at aei.mpg.de (Frank =?utf-8?Q?L=C3=B6ffler?=)
Date: Mon, 21 May 2007 09:32:02 +0200
Subject: [Developers] Problems with make -j
In-Reply-To: <B1B51298-A451-4886-8083-186EECF89E15@cct.lsu.edu>
References: <B1B51298-A451-4886-8083-186EECF89E15@cct.lsu.edu>
Message-ID: <20070521073202.GQ26063@peterpan.ap.op.sissa.it>

On Sun, May 20, 2007 at 11:58:26AM -0500, Erik Schnetter wrote:
> Has anybody observed this as well?

Yes.

>  Do you know what the cause could be?

Unfortunately not. I suspect it could be how make distributes the
"slots" over subdirectories, which can result in less jobs running
simultaneously than specified.

Frank


From diener at cct.lsu.edu  Mon May 21 11:48:24 2007
From: diener at cct.lsu.edu (Peter Diener)
Date: Mon, 21 May 2007 11:48:24 -0500 (CDT)
Subject: [Developers] Problems with make -j
In-Reply-To: <B1B51298-A451-4886-8083-186EECF89E15@cct.lsu.edu>
References: <B1B51298-A451-4886-8083-186EECF89E15@cct.lsu.edu>
Message-ID: <Pine.LNX.4.64.0705211145540.4171@amarok.cct.lsu.edu>

Hi,


On Sun, 20 May 2007, Erik Schnetter wrote:

> Sometimes when I build a Cactus configuration with "make -j4", the "-j4" 
> option is ignored, and make builds sequentially.  I think this occurs mostly 
> when the CST stage needs to run.
>
> Has anybody observed this as well?  Do you know what the cause could be?

I have seen this as well. And I agree with the observation that it happens 
when the CST is run.

> Maybe related is the fact that, when configuring, Cactus picks up the options 
> "-fds 3,4", which are used by make to communicate between sub-makes to ensure 
> that no more than 4 processes are running at the same time.  Could this maybe 
> confuse make?

I have no idea...

Cheers,

   Peter

From tradke at aei.mpg.de  Mon May 21 04:00:53 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Mon, 21 May 2007 11:00:53 +0200
Subject: [Developers] Problems with make -j
In-Reply-To: <B1B51298-A451-4886-8083-186EECF89E15@cct.lsu.edu>
References: <B1B51298-A451-4886-8083-186EECF89E15@cct.lsu.edu>
Message-ID: <46515FC5.5080703@aei.mpg.de>

Erik Schnetter wrote:
> Sometimes when I build a Cactus configuration with "make -j4", the "- 
> j4" option is ignored, and make builds sequentially.  I think this  
> occurs mostly when the CST stage needs to run.
> 
> Has anybody observed this as well?  Do you know what the cause could be?

I've observed this as well. For the nightly Cactus integration tests I'm 
using TJOBS=4 now which always works.

-- 
Cheers, Thomas.

From bzink at cct.lsu.edu  Mon May 21 14:42:16 2007
From: bzink at cct.lsu.edu (Burkhard Zink)
Date: Mon, 21 May 2007 14:42:16 -0500
Subject: [Developers] Problems with make -j
In-Reply-To: <B1B51298-A451-4886-8083-186EECF89E15@cct.lsu.edu>
References: <B1B51298-A451-4886-8083-186EECF89E15@cct.lsu.edu>
Message-ID: <4651F618.5090700@cct.lsu.edu>

Erik Schnetter wrote:
> Sometimes when I build a Cactus configuration with "make -j4", the 
> "-j4" option is ignored, and make builds sequentially.  I think this 
> occurs mostly when the CST stage needs to run.
>
> Has anybody observed this as well?  Do you know what the cause could be?
Absolutely; I usually just restart make -j after the CST phase is completed.

B

From schnetter at cct.lsu.edu  Mon May 21 16:01:11 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 21 May 2007 16:01:11 -0500
Subject: [Developers] Problems with make -j
In-Reply-To: <4651F618.5090700@cct.lsu.edu>
References: <B1B51298-A451-4886-8083-186EECF89E15@cct.lsu.edu>
	<4651F618.5090700@cct.lsu.edu>
Message-ID: <CDFBCB59-20C6-4382-A895-DC0CE78870B2@cct.lsu.edu>

On May 21, 2007, at 14:42:16, Burkhard Zink wrote:

> Erik Schnetter wrote:
>> Sometimes when I build a Cactus configuration with "make -j4", the
>> "-j4" option is ignored, and make builds sequentially.  I think this
>> occurs mostly when the CST stage needs to run.
>>
>> Has anybody observed this as well?  Do you know what the cause  
>> could be?
> Absolutely; I usually just restart make -j after the CST phase is  
> completed.

I think this could be cause by the way in which Cactus builds the  
executable.  It creates a file make.thornlist, then it includes that  
file into the makefile to build the thorns.  That means that make has  
to read the makefile twice.  Make knows how to do this, but the rules  
how this are done are a bit complicated, and it apparently confuses  
make, so that it doesn't do parallel builds any more.

I have committed a change which makes Cactus build the thorns in two  
steps, which solved this problem for me.  Try updating the flesh  
(including the main Makefile and the lib/make subdirectory).

-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/developers/attachments/20070521/ee11f17e/attachment.bin 

From schnetter at cct.lsu.edu  Wed May 23 21:34:06 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 23 May 2007 21:34:06 -0500
Subject: [Developers] Scheduling MoL_PostStep in POSTREGRID
Message-ID: <7A26CD38-C294-4DA7-86ED-D453EAC0BCD1@cct.lsu.edu>

CactusBase/MoL schedules the group MoL_PostStep in the POSTRESTRICT  
bin.  This is necessary since the boundary conditions need to be re- 
applied after restriction, in case the restricted region is near a  
(symmetry) boundary.  However, the boundary conditions also need to  
be re-applied after regridding, in case the grid structure changes  
near a (symmetry) boundary.  This did not happen until now.

I have therefore also scheduled MoL_PostStep in the POSTREGRID bin.   
This corrects a regridding problem that was reported on the Carpet  
mailing list.  The regridding problem is somewhat difficult to  
detect, since the following time step does apply the boundary  
condition, so that the (symmetry) boundaries of the next output look  
correct.

If your code already schedules either MoL_PostStep or its boundary  
conditions in the POSTREGRID bin, then you did not encounter this  
problem.  Your code now applies the boundary conditions twice after  
regridding.  This is still correct, but of course not necessary.  You  
can examine the schedule (which is printed at startup) to determine  
whether the actions occur in the correct order.

-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/developers/attachments/20070523/c560af73/attachment.bin 

From schnetter at cct.lsu.edu  Wed May 23 22:22:11 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 23 May 2007 22:22:11 -0500
Subject: [Developers] Fwd: [CactusMaint] CactusBase/2090: Patch: Provide
	number of integration substeps
References: <200705240319.l4O3JxgX025086@cactus.cct.lsu.edu>
Message-ID: <8F4C2356-92CF-4C08-8D5B-F113612129C3@cct.lsu.edu>

From: schnetter at cct.lsu.edu
Date: May 23, 2007 10:19:59 PM CDT
To: goodale at cct.lsu.edu, gnats-admin at cactuscode.org,  
cactusmaint at cactuscode.org
Subject: [CactusMaint] CactusBase/2090: Patch: Provide number of  
integration substeps
Reply-To: bugs at cactuscode.org, CactusMaint <cactusmaint at cactuscode.org>

> Number:         2090
> Notify-List:
> Category:       CactusBase
> Synopsis:       Patch: Provide number of integration substeps
> Confidential:   no
> Severity:       non-critical
> Priority:       low
> Responsible:    goodale
> State:          open
> Class:          feature-request
> Submitter-Id:   user
> Arrival-Date:   Wed May 23 22:19:59 -0500 2007
> Originator:     Erik Schnetter
> Release:        Cactus 4.0.b16
> Organization:
> Environment:
> Description:
Provide an aliased function which returns the number of time  
integration substeps of the time integrator.

This information can then be used by Carpet to set the number of  
buffer zones automatically.
> How-To-Repeat:
> Fix:
Unknown
> Unformatted:

-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/developers/attachments/20070523/9baf4b75/attachment.bin 

From Ankush.Gupta at Sun.COM  Wed May 30 07:57:56 2007
From: Ankush.Gupta at Sun.COM (Ankush Gupta)
Date: Wed, 30 May 2007 18:27:56 +0530
Subject: [Developers] Cactus Port to Solaris
Message-ID: <465D74D4.3070701@sun.com>

Hello,

  I was trying to port Cactus to Solaris 10,using gcc and MPICH. On 
loading I get the error of symbols like (send recv etc. ).
  When I had set the LD_FLAGS env variables to "-lsocket -lnsl".It works 
fine. I wanted to add that to known-configurations
  solaris 2.10

#! /bin/sh
#  /*@@
#    @file      solaris2.11
#    @date      April 6th 2004
#    @author    Gabrielle Allen
#    @desc
#  #    @enddesc
#    @version $Header: 
/cactus/Cactus/lib/make/known-architectures/solaris2.11,v 1.1 2004/04/07 
17:28:05 allen Exp $
#  @@*/

#. $srcdir/known-architectures/solaris
LD_FLAGS="$LDFLAGS -L/usr/lib -lnsl -lsocket"
LIBS="socket nsl m"

It dint pick up those flags. So I wanted to know how could I set those 
flags so that it uses them for compiling cactus.

Thanks
Ankush

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cactuscode.org/pipermail/developers/attachments/20070530/3b132a52/attachment.html 

From tradke at aei.mpg.de  Wed May 30 11:33:45 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Wed, 30 May 2007 18:33:45 +0200
Subject: [Developers] Cactus Port to Solaris
In-Reply-To: <465D74D4.3070701@sun.com>
References: <465D74D4.3070701@sun.com>
Message-ID: <465DA769.70602@aei.mpg.de>

Ankush Gupta wrote:
> Hello,
> 
>  I was trying to port Cactus to Solaris 10,using gcc and MPICH. On 
> loading I get the error of symbols like (send recv etc. ).
>  When I had set the LD_FLAGS env variables to "-lsocket -lnsl".It works 
> fine. I wanted to add that to known-configurations
>  solaris 2.10
> 
> #! /bin/sh
> #  /*@@
> #    @file      solaris2.11
> #    @date      April 6th 2004
> #    @author    Gabrielle Allen
> #    @desc
> #  #    @enddesc
> #    @version $Header: 
> /cactus/Cactus/lib/make/known-architectures/solaris2.11,v 1.1 2004/04/07 
> 17:28:05 allen Exp $
> #  @@*/
> 
> #. $srcdir/known-architectures/solaris
> LD_FLAGS="$LDFLAGS -L/usr/lib -lnsl -lsocket"
> LIBS="socket nsl m"
> 
> It dint pick up those flags. So I wanted to know how could I set those 
> flags so that it uses them for compiling cactus.

Hi Ankush,

Cactus should automatically detect systems running Solaris 2.6 up to 
2.9. The general known-architectures file for this version of Solaris 
already includes "socket nsl m" in the LIBS makefile variable iff the 
user has not set it manually.

I guess if Solaris 10 isn't completely different from its predecessor 
versions, all you need to do is to add a file 
lib/make/known-architectures/solaris10 with the same contents as one of 
the solaris2.x files. Does this work ?

-- 
Cheers, Thomas.

From Ankush.Gupta at Sun.COM  Thu May 31 00:05:09 2007
From: Ankush.Gupta at Sun.COM (Ankush Gupta)
Date: Thu, 31 May 2007 10:35:09 +0530
Subject: [Developers] Cactus Port to Solaris
In-Reply-To: <465DA769.70602@aei.mpg.de>
References: <465D74D4.3070701@sun.com> <465DA769.70602@aei.mpg.de>
Message-ID: <465E5785.6040407@sun.com>

Hi Thomas

    Ya I had made the same and tried that too.  The following error is 
seen when I try to build the WaveDemo example on Solaris 10 powered by 
AMD 64 processor in this case.

"/usr/include/sys/isa_defs.h", line 462: undefined control
gmake[3]: *** [Check.c.d] Error 2
gmake[2]: *** [make.checked] Error 2
gmake[1]: *** 
[/export/home/ankush/Office_work/port_work/Cactus/cactus_exp/Cactus/configs/WaveDemo/lib/libBoundary.a] 
Error 2
gmake: *** [WaveDemo] Error 2

Thanks
Ankush


Thomas Radke wrote:
> Ankush Gupta wrote:
>   
>> Hello,
>>
>>  I was trying to port Cactus to Solaris 10,using gcc and MPICH. On 
>> loading I get the error of symbols like (send recv etc. ).
>>  When I had set the LD_FLAGS env variables to "-lsocket -lnsl".It works 
>> fine. I wanted to add that to known-configurations
>>  solaris 2.10
>>
>> #! /bin/sh
>> #  /*@@
>> #    @file      solaris2.11
>> #    @date      April 6th 2004
>> #    @author    Gabrielle Allen
>> #    @desc
>> #  #    @enddesc
>> #    @version $Header: 
>> /cactus/Cactus/lib/make/known-architectures/solaris2.11,v 1.1 2004/04/07 
>> 17:28:05 allen Exp $
>> #  @@*/
>>
>> #. $srcdir/known-architectures/solaris
>> LD_FLAGS="$LDFLAGS -L/usr/lib -lnsl -lsocket"
>> LIBS="socket nsl m"
>>
>> It dint pick up those flags. So I wanted to know how could I set those 
>> flags so that it uses them for compiling cactus.
>>     
>
> Hi Ankush,
>
> Cactus should automatically detect systems running Solaris 2.6 up to 
> 2.9. The general known-architectures file for this version of Solaris 
> already includes "socket nsl m" in the LIBS makefile variable iff the 
> user has not set it manually.
>
> I guess if Solaris 10 isn't completely different from its predecessor 
> versions, all you need to do is to add a file 
> lib/make/known-architectures/solaris10 with the same contents as one of 
> the solaris2.x files. Does this work ?
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cactuscode.org/pipermail/developers/attachments/20070531/cb99e5f6/attachment.html 

From tradke at aei.mpg.de  Thu May 31 03:07:10 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Thu, 31 May 2007 10:07:10 +0200
Subject: [Developers] Cactus Port to Solaris
In-Reply-To: <465E5785.6040407@sun.com>
References: <465D74D4.3070701@sun.com> <465DA769.70602@aei.mpg.de>
	<465E5785.6040407@sun.com>
Message-ID: <465E822E.9010703@aei.mpg.de>

Ankush Gupta wrote:
> Hi Thomas
> 
>    Ya I had made the same and tried that too.  The following error is 
> seen when I try to build the WaveDemo example on Solaris 10 powered by 
> AMD 64 processor in this case.
> 
> "/usr/include/sys/isa_defs.h", line 462: undefined control
> gmake[3]: *** [Check.c.d] Error 2
> gmake[2]: *** [make.checked] Error 2
> gmake[1]: *** 
> [/export/home/ankush/Office_work/port_work/Cactus/cactus_exp/Cactus/configs/WaveDemo/lib/libBoundary.a] 
> Error 2
> gmake: *** [WaveDemo] Error 2

A problem with dependency generation. What C preprocessor did you use 
(check the CPP variable in configs/WaveDemo/config-data/make.config.defn) ?
It seems to choke on the include file mentioned above. What's on line 462 ?
Even though makefile dependencies are wrong, you might still be able to 
compile, just by calling 'make WaveDemo' again.

If that doesn't help you could also try configuring Cactus to use its 
own perl-based preprocessor:

   CPP = $${PERL} $${CCTK_HOME}/lib/sbin/cpp.pl

-- 
Cheers, Thomas.

From d.rideout at imperial.ac.uk  Thu May 31 09:19:51 2007
From: d.rideout at imperial.ac.uk (David Rideout)
Date: Thu, 31 May 2007 15:19:51 +0100
Subject: [Developers] parameters as default values of parameters
Message-ID: <200705311519.51633.d.rideout@imperial.ac.uk>

I tried to use the value of another parameter as the default value for a 
parameter, and received nothing besides a level 2 warning from Cactus at 
runtime.  Cactus just silently (well almost silently; I didn't think to set 
-W2 on the command line) set the parameter value to zero.

This seems way too permissive.  Optimally this should be caught by the CST.  
Should this be regarded as a bug?

-David

From goodale at cct.lsu.edu  Thu May 31 09:29:24 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Thu, 31 May 2007 15:29:24 +0100 (BST)
Subject: [Developers] parameters as default values of parameters
In-Reply-To: <200705311519.51633.d.rideout@imperial.ac.uk>
References: <200705311519.51633.d.rideout@imperial.ac.uk>
Message-ID: <Pine.LNX.4.64.0705311528540.31722@fandango.dyndns.org>

On Thu, 31 May 2007, David Rideout wrote:

> I tried to use the value of another parameter as the default value for a
> parameter, and received nothing besides a level 2 warning from Cactus at
> runtime.  Cactus just silently (well almost silently; I didn't think to set
> -W2 on the command line) set the parameter value to zero.
>
> This seems way too permissive.  Optimally this should be caught by the CST.
> Should this be regarded as a bug?

Definitely a bug.