Subject: [Dorsal-dev] Stable build testing

From: Harish Narayanan <[email-masked]>
Date: Fri, 24 Oct 2008 15:52:09 +0200

Greetings all,

In order to efficiently work through some tutorials during an upcoming
workshop, the presenters decided it would be a good idea to have
participants install DOLFIN prior to the event.

I suggested Dorsal for this, and toward this end, I have created a
"stable" version of Dorsal[1] which is very similar to what's in the
mercurial repository, except:

  a. It uses tarballs of the the most recent releases of FEniCS
     packages instead of their mercurial repositories.
  b. It doesn't attempt to build SyFi, UFL (and consequently doesn't
     need GiNaC, CLN), making the build much quicker.

If you have the time, could you please fetch[1] and try it[2] on your
favourite platform (and point out any obvious problems should they crop
up) before I advertise it to the rest of the world?

Thanks,
Harish

[1]
http://home.simula.no/~harish/files/projects/dorsal/dorsal-stable-0.3.tar.bz2

[2]
 0. Download the archive.
 1. Untar it with: tar -xjf dorsal-stable-0.3.tar.bz2
 2. Glance over (and edit if you want) dorsal.cfg
 3. Run ./dorsal.sh (making sure you follow any initial instructions
    for your platform that show up on screen)

---

From: Ilmar Wilbers <[email-masked]>
Date: Fri, 24 Oct 2008 16:29:09 +0200

Currently building Hardy and Intrepid.

I still think that building and installing scons stuff should be done in 
two steps, not in a single step.

ilmar

Harish Narayanan wrote:
> _______________________________________________
> Dorsal-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/dorsal-dev
>

---

From: Joachim Berdal Haga <[email-masked]>
Date: Fri, 24 Oct 2008 16:29:43 +0200

> favourite platform (and point out any obvious problems should they crop

I tried it on intrepid (for the first time), and running a python demo gives:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7f058c0 (LWP 17623)]
0xb6115a04 in MPID_CH_InitMsgPass ()
    from /home/jobh/svn/fenics/build/lib/libdolfin.so.0

Now, the ubuntu openmpi package has never been very high quality, so maybe it's 
another bug there. For the present purposes, maybe it's easiest to pass 
enableMpi=no to dolfin scons?

-j.

---

From: Joachim Berdal Haga <[email-masked]>
Date: Fri, 24 Oct 2008 16:31:12 +0200

> two steps, not in a single step.

It was me who argued for a single step. The extra step takes 60s of build time. 
Why is it better with two?

-j.

---

From: Ilmar Wilbers <[email-masked]>
Date: Fri, 24 Oct 2008 16:34:07 +0200

Because if you do it in a single step, and something fails, you get half 
an installation in your prefix, this is ugly. make/ make install has 
always been done in two steps, the same should apply here. When looking 
at the output, the process of building and installing happens in a mix 
when running in two steps.

ilmar

Joachim Berdal Haga wrote:
>> I still think that building and installing scons stuff should be done 
>> in two steps, not in a single step.
>
> It was me who argued for a single step. The extra step takes 60s of 
> build time. Why is it better with two?
>
> -j.
>

---

From: Harish Narayanan <[email-masked]>
Date: Fri, 24 Oct 2008 16:35:31 +0200

Joachim Berdal Haga wrote:
> Now, the ubuntu openmpi package has never been very high quality, so
> maybe it's another bug there. For the present purposes, maybe it's
> easiest to pass enableMpi=no to dolfin scons?

Does this happen for you too Ilmar?

And no, rather than disabling mpi, I can just turn on the OpenMPI
package for Intrepid if the Ubuntu .debs aren't great.

---

From: Harish Narayanan <[email-masked]>
Date: Fri, 24 Oct 2008 16:37:05 +0200

> two steps, not in a single step.

I have no strong opinions on this. It was initially one step, then made
two steps, then Joachim pointed out to me that two steps added a
sizeable chunk of time on an old gutsy machine of his. So I reverted to
one step.

Joachim?

---

From: Ilmar Wilbers <[email-masked]>
Date: Fri, 24 Oct 2008 16:38:13 +0200

Not quite there yet, am updating the vmware machine.

ilmar

---

From: Ilmar Wilbers <[email-masked]>
Date: Fri, 24 Oct 2008 16:39:20 +0200

Shouldn't the compiling of the c++ demos be turned on? Currently they 
are disabled.

ilmar

---

From: Ilmar Wilbers <[email-masked]>
Date: Fri, 24 Oct 2008 16:40:51 +0200

Weird, noticed they are turned on, but they do not seem to be compiled, 
will check closer.

ilmar

---

From: Joachim Berdal Haga <[email-masked]>
Date: Fri, 24 Oct 2008 16:42:12 +0200

> sizeable chunk of time on an old gutsy machine of his. So I reverted to

Ilmar's reason is good, so I guess I support changing back. I just wish scons 
wasn't so slow... Anyhow, I'm trying now with openmpi enabled.

=j.

---

From: Harish Narayanan <[email-masked]>
Date: Fri, 24 Oct 2008 16:42:37 +0200

> Weird, noticed they are turned on, but they do not seem to be compiled,

This has always been the case on some platforms. For instance, even
right now, they are compiled on Hardy but not on Leopard.

---

From: Harish Narayanan <[email-masked]>
Date: Fri, 24 Oct 2008 16:44:37 +0200

>    from /home/jobh/svn/fenics/build/lib/libdolfin.so.0

Just for the record: I've tried a demo (1 cpp/1 python) on hardy,
leopard and rhel5. I don't see this segfault in any case.

Harish

---

From: Joachim Berdal Haga <[email-masked]>
Date: Fri, 24 Oct 2008 16:59:00 +0200

> scons wasn't so slow... Anyhow, I'm trying now with openmpi enabled.

grr... "DirNodeInfo instance has no attribute 'csig'"

does that mean I have to build scons as well?

-j.

---

From: Harish Narayanan <[email-masked]>
Date: Fri, 24 Oct 2008 17:02:39 +0200

> grr... "DirNodeInfo instance has no attribute 'csig'"

Yep.

---

From: Ilmar Wilbers <[email-masked]>
Date: Fri, 24 Oct 2008 17:03:20 +0200

Yes, this is fixed in the newest version.

ilmar

---

From: Ilmar Wilbers <[email-masked]>
Date: Fri, 24 Oct 2008 17:03:52 +0200

I know why it takes longer. The demos are not compiled if the whole 
process is done in a single step :-)

ilmar

---

From: Joachim Berdal Haga <[email-masked]>
Date: Fri, 24 Oct 2008 17:11:19 +0200

Ach so. After adding the packages scons and openmpi to intrepid platform, it 
seems to work. "Seems to" is because my upgrade to intrepid screwed up X, so 
plotting doesn't work.

-j.

---

From: Joachim Berdal Haga <[email-masked]>
Date: Fri, 24 Oct 2008 17:13:27 +0200

> process is done in a single step :-)

That was unexpected :-)

But in addition to that, a no-op run of scons, when it decides there's nothing 
to do, takes >60s for me. Much of it in "resolving compiler" etc.

-j/

---

From: Harish Narayanan <[email-masked]>
Date: Fri, 24 Oct 2008 17:15:02 +0200

Joachim Berdal Haga wrote:
> Ach so. After adding the packages scons and openmpi to intrepid
> platform, it seems to work. "Seems to" is because my upgrade to intrepid
> screwed up X, so plotting doesn't work.

But aren't you glad packages for scons, openmpi etc. exist so it's just
a matter of adding a couple of lines to make (and break) things?

---

From: Harish Narayanan <[email-masked]>
Date: Fri, 24 Oct 2008 17:15:50 +0200

Joachim Berdal Haga wrote:
> But in addition to that, a no-op run of scons, when it decides there's
> nothing to do, takes >60s for me. Much of it in "resolving compiler" etc.

Exactly. This annoys me (everyone who notices) tremendously.

---

From: Joachim Berdal Haga <[email-masked]>
Date: Fri, 24 Oct 2008 17:19:37 +0200

> a matter of adding a couple of lines to make (and break) things?

Indeed I am! And that's what makes dorsal worthwhile. The annoying part is that 
I notice these thing the day after intrepid feature freeze, so it's so much 
harder to get intrepid fixed. But if it's a regression since hardy then maybe...

-j.

---

From: Ilmar Wilbers <[email-masked]>
Date: Fri, 24 Oct 2008 17:33:05 +0200

For DOLFIN:
enableResolveCompiler=0 may save quite some time. Only safe if you know 
that your setup (mpic++ compiler etc.) is correct.

ilmar

---

From: Ilmar Wilbers <[email-masked]>
Date: Fri, 24 Oct 2008 18:12:06 +0200

It worked for me on Intrepid.

Have a nice weekend!

ilmar

---

From: Joachim Berdal Haga <[email-masked]>
Date: Fri, 24 Oct 2008 18:37:13 +0200

I had another mpi library (mpich) also installed. I expect it works now that I 
have removed it. [update: yes it does.]

It might be worth mentioning in the platform file for all debian/ubuntu variants 
which uses pre-packaged openmpi:
'If you have other mpi libraries installed, make sure "update-alternatives 
--config mpi" is set to openmpi.'

And I also got GL (and thus viper) to work, so that's me for today.

-j.

---

From: Harish Narayanan <[email-masked]>
Date: Fri, 24 Oct 2008 18:40:40 +0200

Joachim Berdal Haga wrote:
> I had another mpi library (mpich) also installed. I expect it works now
> that I have removed it. [update: yes it does.]
> 
> It might be worth mentioning in the platform file for all debian/ubuntu
> variants which uses pre-packaged openmpi:
> 'If you have other mpi libraries installed, make sure
> "update-alternatives --config mpi" is set to openmpi.'

I will add this. (And this instruction is the only change I'm going to
make to prevent unforeseen breakages and the need for additional testing.)

> And I also got GL (and thus viper) to work, so that's me for today.

Good, so the final tally is: hardy, intrepid, rhel5, leopard. I'd say
that's plenty tested.

---

From: Harish Narayanan <[email-masked]>
Date: Fri, 24 Oct 2008 18:41:01 +0200

> It worked for me on Intrepid.

Cool, thanks!

---

From: Anders Logg <[email-masked]>
Date: Mon, 27 Oct 2008 14:04:58 +0100

I'm getting the following error message when running ./dorsal.sh
without having made any changes on Ubuntu 8.04:

  Unpacking slepc-2.3.3
  Building slepc-2.3.3
  Checking environment...
  ERROR: PETSC_DIR enviroment variable is not valid
  Failure with exit status: 1
  Exit message: There was a problem in build setup for slepc-2.3.3.

My PETSC_DIR is set to /usr/local/lib/petsc which is a symlink to
/usr/local/lib/petsc-2.3.3-p8. I build against this PETSc daily.

-- 
Anders

---

From: Ilmar Wilbers <[email-masked]>
Date: Mon, 27 Oct 2008 14:20:06 +0100

Here are the lines from configure.py:

petscdir = os.environ['PETSC_DIR']
if not os.path.exists(petscdir) or not 
os.path.exists(os.sep.join([petscdir,'bmake'])):
  sys.exit('ERROR: PETSC_DIR enviroment variable is not valid')

Could you verify the existence of th 'bmake' directory in PETSC_DIR? 
Maybe the soft links are the problem?

ilmar

Anders Logg wrote:
> ------------------------------------------------------------------------
>

---

From: Joachim Berdal Haga <[email-masked]>
Date: Mon, 27 Oct 2008 14:23:13 +0100

Nah, it WAS set to /usr/local/something.

After source'ing sid.platform or whatever, it's reset:
export PETSC_DIR=/usr/lib/petsc

-j.

---

From: Anders Logg <[email-masked]>
Date: Mon, 27 Oct 2008 14:26:04 +0100

# ls "$PETSC_DIR/bmake"
adic.init     adicmf.init  docsonly             petscconf
adicmfb.init  common       linux-gnu-cxx-debug

But where is configure.py? I can't it, and I also can't find the
Python code you refer to below anywhere in Dorsal (stable-0.3).

-- 
Anders

---

From: Harish Narayanan <[email-masked]>
Date: Mon, 27 Oct 2008 14:28:41 +0100

> /usr/local/lib/petsc-2.3.3-p8. I build against this PETSc daily.

Is this the default Hardy Petsc? I thought it resided in /usr/lib/petsc.

Harish

---

From: Anders Logg <[email-masked]>
Date: Mon, 27 Oct 2008 14:29:38 +0100

> Is this the default Hardy Petsc? I thought it resided in /usr/lib/petsc.

No, it's my own.

-- 
Anders

---

From: Harish Narayanan <[email-masked]>
Date: Mon, 27 Oct 2008 14:35:40 +0100

>> Is this the default Hardy Petsc? I thought it resided in /usr/lib/petsc.

Then I presume you don't have (an additional) Petsc installed from the
Ubuntu .deb.

Open platforms/hardy.platform and replace the default PETSC_DIR with
your PETSC_DIR. That should probably fix this.

Harish

---

From: Anders Logg <[email-masked]>
Date: Mon, 27 Oct 2008 14:40:41 +0100

> your PETSC_DIR. That should probably fix this.

Yes, but now I get the following:

ERROR: PETSc is not configured for architecture linux-gnu-c-opt

I have configured PETSc for linux-gnu-cxx-debug.

-- 
Anders

---

From: Ilmar Wilbers <[email-masked]>
Date: Mon, 27 Oct 2008 14:43:50 +0100

You need to set
export PETSC_ARCH=linux-gnu-c-opt
to your value in hardy.package.

The code I was referring to earlier was from SLEPc.

ilmar

---

From: Anders Logg <[email-masked]>
Date: Mon, 27 Oct 2008 14:49:06 +0100

> I have configured PETSc for linux-gnu-cxx-debug.

Yes, obviously. Sorry for the stupid questions... Now building :-)

-- 
Anders

---

From: Harish Narayanan <[email-masked]>
Date: Mon, 27 Oct 2008 15:00:47 +0100

> Yes, obviously. Sorry for the stupid questions... Now building :-)

It was assumed that people don't compile and install software that's
available as part of their package managers. This should probably be
revisited. A TODO for a future version!

Harish

---

From: Ilmar Wilbers <[email-masked]>
Date: Mon, 27 Oct 2008 15:12:14 +0100

Should we do something so that if the environents we set in Dorsal 
already are defined, we keep them? Meaning that we do not override 
PETSC_DIR and PETSC_ARCH if they are defined on the system?

ilmar

---

From: Anders Logg <[email-masked]>
Date: Mon, 27 Oct 2008 15:13:51 +0100

That sounds reasonable.

-- 
Anders

---

From: Anders Logg <[email-masked]>
Date: Mon, 27 Oct 2008 15:15:38 +0100

> That sounds reasonable.

And by the way, it worked beatifully now! Nice work.

-- 
Anders

---

From: Harish Narayanan <[email-masked]>
Date: Mon, 27 Oct 2008 15:20:54 +0100

> PETSC_DIR and PETSC_ARCH if they are defined on the system?

Yep. I'll add it to the TODO.

Harish