From jco34 at cornell.edu  Wed Jul  1 13:44:10 2009
From: jco34 at cornell.edu (Jeremy Ong)
Date: Wed, 1 Jul 2009 14:44:10 -0400
Subject: [Developers]  visitCarpetHDF5 bug?
Message-ID: <b308fa0907011144v5a1db18fnfc6ec5c8d1b7bf02@mail.gmail.com>

Updates

After installing Visit 1.11.2_rhel3 and cactus, I encounter a bug in the
visitCarpetHDF5 module (compiled with hdf5 1.8.1).

I encounter this bug when I attempt to open a Cactus generated h5 file with
Carpet installed:

Running: gui1.11.2 -o /home/jeremy/Cactus/runs/scratch/phi.h5
Running: viewer1.11.2 -host 127.0.0.1 -geometry 1514x1030+406+25 -borders
23,3,3,3 -shift 3,25 -preshift 0,-2 -defer -port 5600
Running: mdserver1.11.2 -host 127.0.0.1 -port 5601
*** glibc detected *** /usr/local/visit/1.11.2/linux-intel/bin/mdserver:
free(): invalid pointer: 0x09485820 ***
======= Backtrace: =========
/lib/libc.so.6[0x20c5231]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xc593f1]
/usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0xc36a9d]
/usr/lib/libstdc++.so.6(_ZNSsD1Ev+0x4c)[0xc384ac]
/home/jeremy/.visit/linux-intel/plugins/databases/libMvisitCarpetHDF5Database.so[0x3e5279]
/usr/local/visit/1.11.2/linux-intel/lib/libhdf5.so.5[0x269153e]


Has anybody seen this bug before? If not, can I get some direction as to how
to debug this?

thanks,
jeremy


--
Jeremy Ong
Applied & Engineering Physics
Cornell University


On Thu, Jun 25, 2009 at 9:37 PM, Erik Schnetter <schnetter at cct.lsu.edu>wrote:

> On Jun 25, 2009, at 16:29:58, Eloisa Bentivegna wrote:
>
>  Jeremy Ong ha scritto:
>>
>>> Dear Cactus Users/Developers/Maintainers,
>>>
>>> I am interested in viewing HDF5 output from the Carpet thorns using
>>> Paraview. Does any such module exist? If my understanding is correct,
>>> the HDF5 output from Carpet cannot be converted via h5tovtk because of
>>> the mesh refinements.
>>>
>>> Thank you!
>>>
>>
>> Hey Jeremy,
>>
>> to the best of my knowledge, there isn't one such tool. What you can do,
>> however, is to extract the refinement levels one by one using the -d
>> flag for h5tovtk, e.g.:
>>
>> h5tovtk -d "ADMBASE::alp it=$iteration tl=0 rl=$reflevel c=$processor"
>> -a -v alp.file_$processor.h5
>>
>> thereby creating a .vtk file for each component of each refinement level
>> at each iteration. For large runs, this can easily turn into a
>> nightmare... therefore I'd recommend VisIt and the corresponding plugin.
>>
>>  (I have tried to use Visit, which should have all the necessary
>>> modules in principle, but encountered tremendous difficulty in
>>> building it)
>>>
>>
>> On which architecture are you trying to install VisIt? For the most
>> common ones, there are precompiled binaries that you can download from
>> the VisIt pages, and my experience is that they usually work out of the
>> box. Also, there are public VisIt installations on most Teragrid
>> machines and many other supercomputers.
>>
>
>
> Jeremy
>
> We just gave a Cactus tutorial at the TeraGrid '09 conference.  For this
> tutorial, Eloisa prepared a VisIt executable on Queen Bee, one of the
> TeraGrid machines.  For testing, and to see that things will indeed work
> after you built or installed VisIt, you could copy your data and visualise
> them there.
>
> You can use either VisIt's remote visualisation capabilities, installing a
> binary copy of VisIt 1.11.x on your laptop, and connecting to the VisIt on
> Queen Bee which has the Cactus file reader already installed.
>  Alternatively, you can run VisIt on Queen Bee directly, and use either X
> forwarding or VNC to view the result on your laptop or workstation.
>  Detailed instructions are on <
> http://www.cactuscode.org/Documentation/tutorials/cactustutorialtg2009>.
>
> -erik
>
> --
> Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/<http://www.cct.lsu.edu/%7Eeschnett/>
>
> My email is as private as my paper mail.  I therefore support encrypting
> and signing email messages.  Get my PGP key from <http://pgp.mit.edu>.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cactuscode.org/pipermail/developers/attachments/20090701/161c9144/attachment.html 

From schnetter at cct.lsu.edu  Wed Jul  8 09:31:20 2009
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 8 Jul 2009 16:31:20 +0200
Subject: [Developers] CfP: Component-Based High-Performance Computing (CBHPC
	2009)
Message-ID: <1E0477CA-2DBE-495C-B8DB-2D3FD170C10D@cct.lsu.edu>

The 2009 Workshop on Component-Based High Performance Computing (CBHPC  
2009)

			 15-16 November 2009
			Portland, Oregon, USA
      Collocated with the 22^nd Supercomputing Conference (SC09)
		   http://compframe.org/cbhpc2009/

Overview

   Component and framework technology is mainstream for desktop
   environments, but has lagged in the high-performance computing (HPC)
   community. The reasons for this stem partly from a general lack of
   awareness of component concepts in the community, but mostly from the
   fact that desktop component models sacrifice performance for
   ease-of-use. In addition, HPC uniquely requires component-based  
support
   for patterns special to parallel computing, such as the massively
   parallel single program multiple data pattern. Beyond the special
   requirements of HPC, component concepts promise to provide the same
   benefits as they do in the mainstream: participation by 10's or 100's
   of developers and the ability to support the software complexity that
   the simulation of natural phenomena demand. Likewise, with multi-core
   architecture becomes the norm and cloud computing gaining popularity,
   understanding requirements unique to HPC will enables a new class of
   commercial HPC applications.

   Following the success of past HPC-GECO and CompFrame workshop
   series, the fourth installment of the workshop, CBHPC 2009, aims to
   bring together the developers and users of such technologies, and to
   build an international research community around these issues. This
   year's workshop focuses on the role of component and framework
   technologies in high-performance and scientific computing, and on
   high-level, component-based and innovative programming tools and
   environments to efficiently develop high performance applications and
   exploit them both on individual massively parallel systems and on the
   Grid.

Topics of Interest

   CBHPC welcomes submissions of two types dealing with high-level and
   component-based approaches to HPC and Grid Computing:
     * Component models and frameworks
     * Component-based platforms for Grid, Clouds and large-scale
       facilities
     * Programming environments and paradigms
     * Analysis and comparison of existing programming approaches
     * Integration of different distributed/Grid/HPC programming
       frameworks
     * Tools and Environments for Coupling of Parallel Application codes
     * Application-level and support-level management of performance,  
QoS,
       faults, dynamicity, architecture heterogeneity
     * Application-level QoS contract description and enforcement
     * Advanced middleware systems as a device to efficiently exploit  
Grid
       resources (e.g. high-bandwidth, innovative networks) in high- 
level
       programming environments
     * Case studies and experiments of large and geographic scale
       high-level HPC applications, large-scale data/analysis
     * Applicability of software engineering techniques for  
restructuring
       and integration
     * High-level approaches for emerging HPC architectures, including
       clusters of reconfigurable computing units, multicore processors,
       and other hybrid, hardware accelerator techniques such as GPGPU,
       cell processors, and FPGA.
     * Approaches to component composition, development, deployment,
       repositories, debugging, and testing for components in HPC
       environments

Submissions Guidelines and Workshop Proceedings

   CBHPC welcomes two types of submissions:
    1. Full papers of up to 12 pages which include work not already
       published or under review for publication in other conferences of
       journals.
    2. Extended abstracts of up to 4 pages describing work in progress,
       which is intended to foster discussions of the emerging trends in
       the component-based HPC and exchange of recent ideas as well as
       on-going applications.

   Submissions are accepted only electronically, in PDF format, and must
   conform to the ACM style. Full papers may not exceed 12 pages and
   extended abstracts of work in progress should be no more than 4 pages
   long including all figures, tables, references, and supplementary
   material. Information for authors and reference style files are
   available at
   http://www.acm.org/sigs/publications/proceedings-templates. Papers
   and abstracts should be submitted via workshop submission page at
   (http://www.easychair.org/conferences/?conf=cbhpc09).
   All full papers and extended abstracts will be reviewed by multiple
   program committee members. Accepted papers will be also published
   through the ACM Digital Library after the workshop. The committee  
also
   plans to invite selected full papers from the workshop to be extended
   and published as part of a journal special issue.
   The organizers plan to distribute in electronic form to the attendees
   additional material concerning the accepted works (e.g., software
   tools, demos, and prototypes). Interested authors should contact the
   workshop chairs no later than 18 September 2009.

Important dates

     * Abstract submission: 31 July 2009
     * Full paper or extended abstract submission: 7 August 2009
     * Notification of acceptance: 4 September 2009
     * Camera-ready papers and extended abstracts: 2 October 2009
     * Related software (optional): 18 September 2009

Committees

General Co-Chairs:

     * Rosa M. Badia, Barcelona Supercomputing Center, Spain
     * Nanbor Wang, Tech-X Corporation, USA

Steering Committee:

     * Rob Armstrong, Sandia National Laboratories, USA
     * David E. Bernholdt, Oak Ridge National Laboratory, USA
     * Marco Danelutto, Universita di Pisa, Italy
     * Vladimir S. Getov, University of Westminster/CoreGRID, UK
     * Christian Perez, INRIA, France
     * Masha Sosonkina, Ames Laboratory, USA

Program Committee: (Tentative, pending acceptance)

     * Rob Armstrong, Sandia National Laboratories, USA
     * Mikio Aoyama, Nanzan University, Japan
     * Rosa Badia, Barcelona Supercomputing Center, Spain
     * Purushotham Bangalore, University of Alabama at Birmingham, USA
     * Fran?oise Baude, University of Nice-Sophia Antipolis, France
     * David E. Bernholdt, Oak Ridge National Laboratory, USA
     * Francisco de Carvalho Junior, Universidade Federal do Cear?  
Brazil
     * Massimo Coppola, Institute of Information Science and  
Technologies,
       CNR, Italy
     * Marco Danelutto, Universita di Pisa, Italy
     * Kosta Damevski, Virginia State University, USA
     * Wael Elwasif, Oak Ridge National Laboratory, USA
     * Vladimir S. Getov, University of Westminster, UK
     * Madhu Govindaraju, Binghamton University, USA
     * James Kohl, Oak Ridge National Laboratory, USA
     * Fang Liu, Indiana University, USA
     * Stefan Muszala, Tech-X Corporation, USA
     * Boyana Norris, Argonne National Laboratory, USA
     * Christian Perez, INRIA, France
     * Thierry Priol, INRIA, France
     * Rainer Schmidt, Austrian Research Centers, Austria
     * Masha Sosonkina, Ames Laboratory and Iowa State University, USA
     * Aad van der Steen, HPC Research, The Netherlands
     * Jean-Bernard Stefani, INRIA, France
     * Rainer Stotzka, Forschungszentrum Karlsruhe, Germany
     * Alan Sussman, University of Maryland, USA
     * Nanbor Wang, Tech-X Corporation, USA

-- 
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 <http://pgp.mit.edu>.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20090708/4376ab25/attachment.bin 

From rideout at aei.mpg.de  Tue Jul 21 11:45:31 2009
From: rideout at aei.mpg.de (David Rideout)
Date: Tue, 21 Jul 2009 18:45:31 +0200 (CEST)
Subject: [Developers] [Flesh-cvs] DEVELOPMENT CVS
 "Cactus/lib/make/known-architectures aix6.1.2.0"
In-Reply-To: <20090714155052.2CD918180@asylum.cct.lsu.edu>
References: <20090714155052.2CD918180@asylum.cct.lsu.edu>
Message-ID: <Pine.LNX.4.64.0907211837420.28829@sshserv.aei.mpg.de>

Hi all,

I have always wondered something about known-architectures:  Isn't it possible 
to omit the version number from the file name?  Otherwise one must commit a 
new file for each new version of the OS, which seems not terribly 
maintainable.  Many of these files are identical.
Is the idea that this is a better way to support old versions 
of an OS?  But wouldn't it be better to edit a single known-architectures 
file, based upon details of various versions, than to keep committing new 
files?

Cheers,
David

On Tue, 14 Jul 2009, Erik Schnetter wrote:

> Update of /cactusdevcvs/Cactus/lib/make/known-architectures
> In directory asylum.cct.lsu.edu:/tmp/cvs-serv2578
>
> Added Files:
> 	aix6.1.2.0
> Log Message:
> Add support for AIX 6.1.2.0
>
>
>
> _______________________________________________
> Flesh-cvs mailing list
> Flesh-cvs at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/flesh-cvs
>

From schnetter at cct.lsu.edu  Tue Jul 21 12:15:02 2009
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 21 Jul 2009 12:15:02 -0500
Subject: [Developers] [Flesh-cvs] DEVELOPMENT CVS
	"Cactus/lib/make/known-architectures aix6.1.2.0"
In-Reply-To: <Pine.LNX.4.64.0907211837420.28829@sshserv.aei.mpg.de>
References: <20090714155052.2CD918180@asylum.cct.lsu.edu>
	<Pine.LNX.4.64.0907211837420.28829@sshserv.aei.mpg.de>
Message-ID: <18E77FB3-7D4D-4E22-B4E5-F9ACDE230C4B@cct.lsu.edu>

David

You are probably right.  We could have if statements in the files for  
changes that may be necessary for major OS releases.

-erik

On Jul 21, 2009, at 11:45:31, David Rideout wrote:

> Hi all,
>
> I have always wondered something about known-architectures:  Isn't  
> it possible
> to omit the version number from the file name?  Otherwise one must  
> commit a
> new file for each new version of the OS, which seems not terribly
> maintainable.  Many of these files are identical.
> Is the idea that this is a better way to support old versions
> of an OS?  But wouldn't it be better to edit a single known- 
> architectures
> file, based upon details of various versions, than to keep  
> committing new
> files?
>
> Cheers,
> David
>
> On Tue, 14 Jul 2009, Erik Schnetter wrote:
>
>> Update of /cactusdevcvs/Cactus/lib/make/known-architectures
>> In directory asylum.cct.lsu.edu:/tmp/cvs-serv2578
>>
>> Added Files:
>> 	aix6.1.2.0
>> Log Message:
>> Add support for AIX 6.1.2.0
>>
>>
>>
>> _______________________________________________
>> Flesh-cvs mailing list
>> Flesh-cvs at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/flesh-cvs
>>
> _______________________________________________
> 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 <http://pgp.mit.edu>.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20090721/4ac1f5ab/attachment.bin