libmesh-users — General information for libmesh users

[Libmesh-users] where can I find the definition for xda file?

[seid m. b. n. <mbo...@ya...>]

Hi
I ran the ex1 example and I have some questions.
I am sorry to ask too much.
The one_quad.xda file have some parameters that I
could not understand them.they are as follows:
what does "Num. Element Blocks" mean?
what does Element types in each block mean?(actually
where can I find the definition of Element types for
example quad=5)
There is a line "0 1 2 3" in this file,what does it
mean?
There is an extra column after the coordinates,is it
used for marking for boundary conditions?(if yes where
can I find the definition of boundary conditions and
their appropriate values?)
In the last part there are some numbers.Is it possible
let me know the definition of them?
0 0 0
0 1 1
0 2 2
0 3 3

I look forward to hearing from you

Best Regard

Bostandoost







__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

[Libmesh-users] problem in running the libmesh examples

[seid m. b. n. <mbo...@ya...>]

Hi
I could configure the libmesh and make.
when I want to run ./ex1
it generates errors as follows:
Usage: ./ex1 -d 2 in.mesh [out.mesh]
[0] ex1.C, line 59, compiled Jan 27 2004 at 16:13:01
Aborted
for the other example there exist the same problem.
Is it necessary to set some enviromental variables for
libmesh?

I look forward to hearing from you.

Best Regards

Bostandoost


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: [Libmesh-users] New Solvers & update...

[<lu...@gi...>]

Ben

Your proposed new interface sounds extremely cool. 

 > 1.) Each simulation will have one EquationSystems class.  This can contain
 > multiple Systems of various types.  
 >     (It might be worth making the EquationSystems a singleton?)

Do you want to restrict the equation systems in EquationSystems to one
single mesh. For multi-physics applications it would be useful to be
able to have different mesh refinements for different systems
(e.g. heat transfer and fluid flow). One can even think of problems,
where one domain (e.g. fluid flow) should be a subdomain of the other
(e.g. heat transfer).

 > 2.) Calling EquationSystems::solve() simply calls solve on each of the
 > systems contained in it.  This goes for init(), reinit(), etc...  Therefore
 > the EquationSystems interface is quite similar to that of each individual
 > system.

Is the user still able do decide whether to call es.solve(), or to
call solve() for each systems individually?

 > 3.) The new interface maintains backward compatibility.  However, we can now
 > do some more interesting stuff, too.  In the past, all systems got a matrix,
 > which is super-stupid and wasteful for field data or post-processed
 > quantities.  Now the idea is that something like this will work:
 > 
 > EquationSystems es(mesh);

Here I would like to be able to say either es(mesh) for a shared mesh,
or 

es.system("S1").add_mesh(mesh1)
es.system("S2").add_mesh(mesh2)

Which such an approach, some quantities would have to be mapped from
mesh to mesh. OTOH one would be able to define different (overlapping)
problem domains and refine the each mesh based on different error
estimators.

 > es.add_system<ImplicitSystem>                    ("S1"); // Create a
 > standard implicit system. solve() solves Ku=f
 > es.add_system<Nonlinear<ImplicitSystem> > ("S2"); // Create a nonlinear
 > implicit system. solve() solves K(u)u=f(u)
 > es.add_system<ExplicitSystem>                   ("S3"); // An explicit
 > system, no matrix.

cool.

 > 4.) Now, the solvers can operate on an individual system *or* the entire
 > EquationSystems. Above "Nonlinear<>" is a solver acting on an individual
 > system.  But consider this example:
 > 
 > Transient<> solver (es);
 > 
 > solver.solve();

 > Here "Transient<>" is a solver acting on an entire EquationSystems object.
 > In this case, the solver will execute a timestep loop and call es.solve() at
 > each time step.  Now, suppose instead I want a transient loop with
 > adaptivity at each time step?
 > No problem:
 > 
 > Transient<Adaptive<> > solver(es);

Where is the adaptivity happening? On the global mesh object? What
happens if two solvers are declared adaptive?

 > Oh, what about a transient loop with adaptivity at each timestep, and a
 > nonlinear loop inside each adaptive loop? Well,
 > 
 > Transient<Adaptive<Nonlinear<> > > solver(es);

 > This is where it is all going.  The interface needs a little more work...
 > The user should be able to add pre and post-processing functions that get
 > called at specified increments to do things like write the solution at each
 > time step, etc...  I just wanted to check this in so that we can get more
 > people interested in it.  

This is a very good point. I think that the calculation of
intermediate state variables and the definition of post-variables is
the same. It would be nice to obtain these quantitites remapped on the
current (refined) grid.

Thanks for sharing your thoughts 

Martin

[Libmesh-users] New Solvers & update...

[KIRK, B. (JSC-E. (NASA) <ben...@na...>]

As some of you may know, I am now working at NASA's Johnson Space Center
doing CFD for hypersonic aerodynamic applications.  The network setup is a
little backwards around here, so it will be a couple of days before I can
check in/out at work.  For some reason they restrict where I ssh.

Anyway, I checked in a lot of changes last week when I got back from North
Carolina.  Now, most of these were trivial (changing Copyright 2002-2003 to
2002-2004) and don't warrant discussing, but the new solver stuff is a
little more interesting.



The basic idea is this:

1.) Each simulation will have one EquationSystems class.  This can contain
multiple Systems of various types.  
    (It might be worth making the EquationSystems a singleton?)

2.) Calling EquationSystems::solve() simply calls solve on each of the
systems contained in it.  This goes for init(), reinit(), etc...  Therefore
the EquationSystems interface is quite similar to that of each individual
system.

3.) The new interface maintains backward compatibility.  However, we can now
do some more interesting stuff, too.  In the past, all systems got a matrix,
which is super-stupid and wasteful for field data or post-processed
quantities.  Now the idea is that something like this will work:

EquationSystems es(mesh);

es.add_system<ImplicitSystem>                    ("S1"); // Create a
standard implicit system. solve() solves Ku=f
es.add_system<Nonlinear<ImplicitSystem> > ("S2"); // Create a nonlinear
implicit system. solve() solves K(u)u=f(u)
es.add_system<ExplicitSystem>                   ("S3"); // An explicit
system, no matrix.

4.) Now, the solvers can operate on an individual system *or* the entire
EquationSystems. Above "Nonlinear<>" is a solver acting on an individual
system.  But consider this example:

Transient<> solver (es);

solver.solve();

Here "Transient<>" is a solver acting on an entire EquationSystems object.
In this case, the solver will execute a timestep loop and call es.solve() at
each time step.  Now, suppose instead I want a transient loop with
adaptivity at each time step?
No problem:

Transient<Adaptive<> > solver(es);

solver.solve();

Oh, what about a transient loop with adaptivity at each timestep, and a
nonlinear loop inside each adaptive loop? Well,

Transient<Adaptive<Nonlinear<> > > solver(es);
...



-------------------------------------------

This is where it is all going.  The interface needs a little more work...
The user should be able to add pre and post-processing functions that get
called at specified increments to do things like write the solution at each
time step, etc...  I just wanted to check this in so that we can get more
people interested in it.  

Steffen:  I think that in this framework we can easily add an EigenSolver,
and then have:

Eigen<> solver (es);
solver.solve(); 



-Ben

[Libmesh-users] State variables

[<an...@tn...>]

Hi

How should state variables (e.g. temperature) be defined? I tried to
use a quantity added with system.add_vector("temperature"), but I
cannot get the variable projected on a refined mesh. 

system.add_vector("T");

// here is the refinement

es.reinit();  // should this already do the projection of _other_vectors??
system.project_vector(system.get_vector("T"));

gives a runtime error message

/numeric/libmesh/include/numerics/petsc_vector.h:604: T
PetscVector<T>::operator()(unsigned int) const [with T = Real]:
Assertion `((i >= this->first_local_index()) && (i <
this->last_local_index()))' failed.

make: *** [run] Aborted

Even if this would work, I do not see how I can calculate an updated
state variable (based on the current solution) and store it in the
vector. 

Is this the way to go? Or should I use another (trivial) system for
the state variable (as Ben suggested for calculated output
quantities)? 

Thanks for enligthenment!

Martin

Re: [Libmesh-users] Saving calculated quantity

[Benjamin S. K. <be...@cf...>]

I will be taking a few days vacation after Christmas, and I will start=20
coding up the improved system support that I've been hyping up for a=20
while.  That should make this a lot simpler.

What you can do in the meantime is add another *system* with some=20
variables that will be used for plotting purposes.  If you don't provide=20
an assemble function for this system there should be no linear solve.

Also, sometimes it is useful to have a linear solve to compute your=20
post-processing variables.  For instance, if you have a C0 solution then=20
the stresses aren't uniquely defined at the nodes, but you can solve an=20
L2 projection system to get a smooth stress field.  Something like this:

es.add_system("Post-Processing");
es("Post-Processing").add_variable("stress");

...

Then assemble the L2 projection system like this:

compute du/dx

phi(i)*phi(j)  =3D phi(i)*du/dx

and solve it in a standard way.

This type of system will be trivially easy to solve since it is SPD=20
(just a mass matrix).

Let me know if you have any more questions.

-Ben





Martin L=FCthi wrote:

>John
>
>John Peterson writes:
> > Martin L=3DFCthi writes:
> >  > Is there an easy way to output calculated quantities to the GMV ou=
tp=3D
> > ut
> >  > files? I want to calculate e.g. stresses (or some other quantitiy
> >  > which is not a system variable), and hav it appear in the output f=
il=3D
> > e.
> > You might add it as a "dummy" system variable which is just
> > computed via a post-processing step.  Then it could be written
> > out as normal to gmv.
>
>Thanks for the answer. There is a problem with this. If I add the
>variable the beginning, the system gives a null solution (because the
>variable is not used in the element loop). Adding it after just before
>the write command results in some runtime error messages.
>
>I was thinking about using an additional vector with
>system.add_vector.
>
>Best, Martin
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IBM Linux Tutorials.
>Become an expert in LINUX or just sharpen your skills.  Sign up for IBM'=
s
>Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
>Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
>_______________________________________________
>Libmesh-users mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libmesh-users
> =20
>

[Libmesh-users] Saving calculated quantity

[<an...@tn...>]

John

John Peterson writes:
 > Martin L=FCthi writes:
 >  > Is there an easy way to output calculated quantities to the GMV outp=
 > ut
 >  > files? I want to calculate e.g. stresses (or some other quantitiy
 >  > which is not a system variable), and hav it appear in the output fil=
 > e.
 > You might add it as a "dummy" system variable which is just
 > computed via a post-processing step.  Then it could be written
 > out as normal to gmv.

Thanks for the answer. There is a problem with this. If I add the
variable the beginning, the system gives a null solution (because the
variable is not used in the element loop). Adding it after just before
the write command results in some runtime error messages.

I was thinking about using an additional vector with
system.add_vector.

Best, Martin

[Libmesh-users] Saving calculated quantity

[John P. <pet...@cf...>]

Martin L=FCthi writes:
 > Is there an easy way to output calculated quantities to the GMV outp=
ut
 > files? I want to calculate e.g. stresses (or some other quantitiy
 > which is not a system variable), and hav it appear in the output fil=
e.
You might add it as a "dummy" system variable which is just
computed via a post-processing step.  Then it could be written
out as normal to gmv.


-John

[Libmesh-users] Saving calculated quantity

[<an...@tn...>]

Hi

Is there an easy way to output calculated quantities to the GMV output
files? I want to calculate e.g. stresses (or some other quantitiy
which is not a system variable), and hav it appear in the output file.

Thanks, Martin

Re: [Libmesh-users] Compiling examples on OS X

[<kp...@id...>]

Hi Ben,

Thank you very much for responding.

I found the following from somebody that seems to have run into a similar
problem with GCC 3.3 on OS X:

http://iua-mail.upf.es/mailman/public-archives/clam/msg00092.html

I'll ask around and try to set up a temporary account on my machine,
although I'm not sure about how to handle the firewall.

libMesh looks promising; looking forward to trying it out for my finite
volume project!

Cheers

Kyle

> Hm.... I don't know what is going on there.  I only have access to an
> OSX 10.2 machine, and it seems to have other problems.  When I use
> ranlib on linux I get no problems:
>
> voyager(11)$ ranlib libmesh.a
> voyager(12)$
>
> I'm not sure what  I can do until I get an account on a 10.3 machine.
> If I can get a temporary account on one of your machines I might be able
>  to look into it...
>
> -Ben
>
>
>
> kp...@id... wrote:
>
>>Hi,
>>
>>Thanks for the input on compiling libMesh on OS X.  The library
>> compiles and links successfully with --disable-shared, however I can't
>> figure out how to get the examples to work correctly.  I used ranlib on
>> the
>>contributed libraries to generate a table of contents, which seemed to
>> work; however, when I run this on libmesh.a I get error messages saying
>> that:
>>
>>- several objects contain no symbols
>>- there are multiple references of at least one symbol
>>
>>I am using OS X 10.3 and GCC 3.3.
>>
>>Any thoughts on how to fix this would be welcome!
>>
>>Thanks
>>
>>Kyle Passarelli
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: SF.net Giveback Program.
>>Does SourceForge.net help you be more productive?  Does it
>>help you create better code?  SHARE THE LOVE, and help us help
>>YOU!  Click Here: http://sourceforge.net/donate/
>>_______________________________________________
>>Libmesh-users mailing list
>>Lib...@li...
>>https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>

[Libmesh-users] Variables numbering (Bloc Matrix)

[Buffat M. <bu...@uf...>]

Hi,
 congratulations for the great job you're doing.
 I am implementing FV formulation using the MONOMIAL  element for CFD 
(compressible). I am solving a coupled system of 5 equations.
As I understand, the dof variable numbering in libmesh is one variable after 
the other: ie.  for 5 variables RHO, U,V,W, E  per element the dof numbering 
is (for N elements):
R1 ..... RN U1 ... UN V1...VN  W1...WN E1 ... EN
For my problem, it is not optimal: i.e. a block numbering is more appropriate 
i.e.
R1 U1 V1 W1 E1  R2 U2 V2 W2 E2 ...... RN UN VN WN EN
as it allows the use of the sparse bloc matrix structure of PETSC with 
MatCreateMPIBAIJ()

Is it possible to change the dof variable numbering in libmesh without too 
much effort. I have a good knowledge of  OOP and C++. 

I have also found a BUG in petsc_vector.h for the operator()(unsigned int i)
the patch is attached.
Thanks,
	Marc


-- 
Marc BUFFAT, Pr. Universite Claude Bernard LYON I 
tel:  (33) 04/72/43/11/02 (UCBL)
fax:  (33) 04/72/44/80/54
bu...@uf... | http://p2chpd-cluster.univ-lyon1.fr

[Libmesh-users] Some questions about the libmesh and debian (new thread)

[Leopold P. A. <le...@wo...>]

Dear Benjamin,

thank's for the email. 

> I saw the email but did not see the patch...  would you send it again,
> please?  I am interested in what they suggest.

It's copied in the end of the mail. I think that the importants points are:

- if you want to link something against PETSc, you should
*not* be using variables like MPI_LIB, but variables like PETSC_MAT_LIB,
PETSC_TS_LIB, etc., which include PETSC_EXTERNAL_LIB_BASIC, which in
turn includes MPI, MPE if present, X11, BLAS and LAPACK, etc.  

I don't know how is linked libmesh or the examples with PETSc, but using it in 
this way, you need to change the flag 
ifeq ($(PETSC_MPI),mpich)
   MPI_HOME       = /usr/lib/mpich
   MPI_LIB        = -L${MPI_HOME}/lib/shared \

                    -L${MPI_HOME}/lib -lmpich -lmpe

   MPIRUN         = /usr/bin/mpirun.mpich
   MPI_INCLUDE    = -I${MPI_HOME}/include
endif

adding the -lmpe as we found some days ago. The debiar mantainer think that 
it's not the correct way.
>
> I have been reworking the configure system to better support some of the
> more complicated packages like PETSc and MPI, so I hope that this issue
> will be resolved soon.  I have been away from email lately, so I haven't
> been able to give this much opinion.

Ok

>
> Until I see the patch I can't comment on whether the Debian maintainer
> is "right" or "wrong."  It is curious, though, that Debian is the only
> architecture where this is an issue.

Well, the Debian people is very strict in very things.

> PETSc configuration is a difficult issue since they can depend on *so*
> many additional packages.  Unfortunately, their only suggestion for
> mitigating the difficulty is to "use their makefiles," which is not an
> option for a package like libMesh that does not *require* PETSc.

Well, the problem was on the examples, not on libmesh. Libmesh compile without 
any problem.

Otherwise, I think that the debian mantainer suggestion is just a suggestion, 
something that I think that it's worthwhile to look, that's all. 


Best regards,

Leo
 -------------------------------------------------------
--------  Missatge transmès  ----------

Subject: Re: Maybe a bug in libpetsc-2.1.6
Date: Dimecres 19 Novembre 2003 20:28
From: Adam C Powell IV <haz...@de...>
To: Leopold Palomo Avellaneda <le...@wo...>

Hello,

Two things:

        1. You can get woody petsc 2.1.6 (adjusted so it builds with the
           older mpich) by adding the following line to
           /etc/apt/sources.list deb http://lyre.mit.edu/~powell/debian
           woody math
        2. Either way, MPI_LIB is not meant to have all of the mpich
           link flags.  If you scroll further down in
           bmake/linux*/packages, you'll see "Location of MPE" with the
           MPE flags which are necessary for linking.

In general, if you want to link something against PETSc, you should
*not* be using variables like MPI_LIB, but variables like PETSC_MAT_LIB,
PETSC_TS_LIB, etc., which include PETSC_EXTERNAL_LIB_BASIC, which in
turn includes MPI, MPE if present, X11, BLAS and LAPACK, etc.  If you
install petsc2.1.6-doc, and unpack the src.tar.gz file with all the
examples, you'll see that this is how those makefiles do things.  [I've
also put together a petsc.m4 which defines these things, but only if you
use autoconf/automake.]

If libmesh is trying to directly use MPI_LIB, then that's a bug in
libmesh, due to a misunderstanding of how to link against the PETSc
libraries.

Also, the README.Debian in the -dev package gives the address of the
"package homepage" http://lyre.mit.edu/~powell/debian.html , which among
other things has a link to my aptable archive with the woody backport of
PETSc 2.1.6 (mentioned above).

On Wed, 2003-11-19 at 06:00, Leopold Palomo Avellaneda wrote:
> Dear Adam C. Powell,
>
> I have a question of the petsc package (version 2.1.6, from sid) and I
> don't know if is a bug in the debian package or not.
>
> I'm trying to use a library (libmesh) that need mpi and petsc. There's no
> debian package, so I tried to compile myself.
>
> I had some errors with the petsc2.1.3 version so I decided to use
> petsc2.1.6. I realised, because of the control file, that to backported
> petsc2.1.6 I needed to backport mpich package. So I did it first. You know,
> sources, fakeroot debian/rules binary. Ok, no problems, a have a debs 
thathttp://lyre.mit.edu/~powell/debian
> works Ok.
>
> I installed the mpich package, the backported 1.2.5 version.
>
> After I compiled the petsc package, and I obtain my need debs files of
> petsc2.16 and I installed it.
>
> When I tried to compiled the library libmesh I had this errors at link:
> [verbose errors snipped]
> In the libmesh list, we have realised that the pets-bmake have this values:
> [....]
> # For mpich:
> ifeq ($(PETSC_MPI),mpich)
>   MPI_HOME       = /usr/lib/mpich
>   MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
>   MPIRUN         = /usr/bin/mpirun.mpich
>   MPI_INCLUDE    = -I/usr/lib/mpich/include
> endif
> [....]
> but, if I change this line
> -  MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
> +   MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
> -lmpe
>
> now the error dissapears and all is ok. So I deduce that if petsc2.1.6
> depends of mpi version 1.2.5, and that version had the mpe library, so
> maybe, if you want to link to a petsc library, you need to add -lmpe to
> your programs. That's all.
>
> Is this a bug in the debian package? I don't know.
>
> Please tell me something, I will comment to the libmesh.

Great, thanks for looking into this.  It's still possible there's a bug
in my package, but I suspect the problem is in libmesh.

Let me know if you need any further assistance.
--
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: [Libmesh-users] Compiling examples on OS X

[Benjamin S. K. <be...@cf...>]

Hm.... I don't know what is going on there.  I only have access to an 
OSX 10.2 machine, and it seems to have other problems.  When I use 
ranlib on linux I get no problems:

voyager(11)$ ranlib libmesh.a
voyager(12)$

I'm not sure what  I can do until I get an account on a 10.3 machine.  
If I can get a temporary account on one of your machines I might be able 
to look into it...

-Ben



kp...@id... wrote:

>Hi,
>
>Thanks for the input on compiling libMesh on OS X.  The library compiles
>and links successfully with --disable-shared, however I can't figure out
>how to get the examples to work correctly.  I used ranlib on the
>contributed libraries to generate a table of contents, which seemed to
>work; however, when I run this on libmesh.a I get error messages saying
>that:
>
>- several objects contain no symbols
>- there are multiple references of at least one symbol
>
>I am using OS X 10.3 and GCC 3.3.
>
>Any thoughts on how to fix this would be welcome!
>
>Thanks
>
>Kyle Passarelli
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?  SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>Libmesh-users mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libmesh-users
>  
>

[Libmesh-users] Boost Your Car's Gas Mileage 27%+.....cutter

[Howard H. <o54...@ya...>]

FUEL SAVER PRO

This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn bet=
ter using three patented processes from General Motors.
www.eoei.com?axel=3D49

PROVEN TECHNOLOGY
A certified U.S. Environmental Protection Agency (EPA) laboratory recently=
 completed tests on the new Fuel Saver. The results were astounding! Maste=
r Service, a subsidiary of Ford Motor Company, also conducted extensive em=
issions testing and obtained similar, unheard of results. The achievements=
 of the Fuel Saver is so noteworthy to the environmental community, that C=
ommercial News has featured it as their cover story in their June, 2000 ed=
ition.

Take a test drive Today - www.eoei.com?axel=3D49






No more advertisements, thanks - http://www.5jzd.org/out5s/pre-rem2e.asp































muvenpyu tlxzqfnf 
wjasxgyxxo 
mefujbsjayt  modpqayoicnamqx qo  veck  tqfx
mhdzqrrk yyz  l io

Re: [Libmesh-users] hp elements

[Luca A. <la...@im...>]

Thanks for the complete feedback. It was very helpful. 
 I agree with Ben that one probably wouldn't need to generalize up to the 
point of having different families in the same mesh (although this could 
potentially be a cool feature, thinking about large scale problems). 
 I'm interested in implementing Dubiner's orthogonal basis (see Sherwin
and Karniadakis, Int J Num Meth Eng 1995). I noticed that the high-order
Gaussian quadrature rules implemented in libMesh already use the same kind
of shifted product. It's not so aesthetically pleasing as it doesn't
produce a symmetric nodal distribution, but it's nice as it's the product
of 1D Jacobi polynomials, which is what I need. Is there any particular
families you guys were thinking about? I'm looking right now into
Adjerid's base mentioned by Daniel. There's also a non-product basis
employed by Hesthaven and Warburton based on the 3d multivariate Legendre
polynomials which preserves symmetry. Probably the choice should be 
oriented towards the basis which makes it easier to express the hanging 
node constraints.

Luca


On Fri, 5 Dec 2003, Benjamin S. Kirk wrote:

> Thanks, Daniel, for that complete overview!
> 
> As Daniel said, right now (non-infinite) finite elements are defined by 
> an order (p) and a family.  The order simply defines the polynomial 
> degree that is used for the approximation space, and the family defines 
> the type of shape functions that are used.  Right now both are constant 
> for the entire mesh.
> 
> Unless someone has a good reason I haven't thought of, I see no need to 
> support variable *families*.  That is, if you want to use hierarchic 
> shape functions, you will use hierarchic shape functions on all 
> elements.  This will greatly simplify matters...  Can you imagine what a 
> pain it would be to handle solution projection in an efficient manner 
> when there may be h,p, *and* family changes going on??
> 
> However, the constant p restriction is probably the one you want 
> removed, and the good news is that it shouldn't be that hard.  There are 
> just a few things that need to happen:
> 
> 1.)  each DofObject (and, by inheritance, elements) should get an 
> order() that defines the approximation order on the element.  The 
> order() for nodes is determined by the elements connected to them.   -- easy
> 
> 2.) The reinit() member in the finite element objects will need to get a 
> little smarter & recompute data every time P changes.  This could be 
> implemented carefully to be really efficient.  For example, behind the 
> scenes we should probably cache element types of various orders so that 
> everything does not get recomputed for each element.
>  -- tricky
> 
> 3.) Hanging node constraints must be generalized for all families and 
> orders -- not trivial
> 
> 4.) The solution projection algorithm needs to be generalized -- easy
> 
> 
> That's it, as I see it...  there might be some complications for the 
> infinite elements that I am not aware of?
> 
> -Ben
> 
> 
> 
> Daniel Dreyer wrote:
> 
> >As already mentioned by Ben, there is no obstacle in the way.
> >Actually, here some more details that arose during the implementation
> >of the infinite elements (which are actually also p-FEM, but with
> >anisotropic p-order, therefore we have _two_ Order enums, namely the
> >radial_order and the base_order in FEType, when ENABLE_INFINITE_ELEMENTS
> >is active):
> >
> >
> >- momentarily, libmesh already offers p-FEM, but with only constant
> >  p-order throughout the mesh.  This order is (currently) determined
> >  once for all through the FEType that you have to create in the
> >  EquationSystems/SystemBase-child context, when you say add_variable().
> >  (note that there is also the simplified variant of add_variable()
> >   which only takes an order, and assumes LAGRANGE as family, which
> >   only goes up to p=2, use instead e.g. HIERARCHIC).
> >
> >  In the FEType, you say what order = p you want.  This information is
> >  then broadcasted to all objects that may handle a degree of freedom:
> >  The DofObject.  Each DofObject may hold _multiple_ components per
> >  dof...
> >
> >  E.g. you have an EDGE3, but you want to use p=3.  Then you have
> >  4 dof:
> >         o----o----o
> >  dof:   0   2,3   1
> >  node:  0    2    1
> >
> >  This is also the numbering scheme in libmesh, first number the nodes
> >  that belong to the first-order element, then number the dofs on the
> >  second-order-nodes (this is particularly helpful when having a 2nd-order
> >  mesh, but you only want to use 1st-order shapes).
> >  the DofObject->n_comp() gives then for:
> >
> >  Node(0) = 1
> >  Node(1) = 1
> >  Node(2) = 2
> >
> >  And since both Node and Elem derive from DofObject,
> >  you may easily handle bubble shapes etc, consult the HIERARCHIC family.
> >
> >
> >- note that you have to --enable-expensive (or so) in ./configure to
> >  get the full support.
> >
> >
> >- GOOD news: the truly tedious work of coding the shapes is already
> >  in progress, _several_ new p-FEM families are underway: Steffen and
> >  Hendrik have already come a long way implementing them, like the ones
> >  that want to orthogonalize the stiffness matrix (integrated Legendre),
> >  improved variants (by Adjerid), and two more pretty interesting
> >  families that also seem to work well on simplices.
> >
> >  I suggest you contact Steffen directly for more information.  As far
> >  as i know, he almost finished debugging 2D, and wants to proceed to 3D.
> >  So perhaps some collab' may be possible.
> >
> >
> >- extending to variable-order-p-FEM is an issue i already thought of
> >  in the context of the infinite elements, and also talked to Ben about
> >  it.  So, feel free to contact for a more detailed discussion.
> >
> >Daniel
> >
> >  
> >
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: SF.net Giveback Program.
> >>Does SourceForge.net help you be more productive?  Does it
> >>help you create better code?  SHARE THE LOVE, and help us help
> >>YOU!  Click Here: http://sourceforge.net/donate/
> >>_______________________________________________
> >>Libmesh-users mailing list
> >>Lib...@li...
> >>https://lists.sourceforge.net/lists/listinfo/libmesh-users
> >>
> >>    
> >>
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by OSDN's Audience Survey.
> >Help shape OSDN's sites and tell us what you think. Take this
> >five minute survey and you could win a $250 Gift Certificate.
> >http://www.wrgsurveys.com/2003/osdntech03.php?site=8
> >_______________________________________________
> >Libmesh-users mailing list
> >Lib...@li...
> >https://lists.sourceforge.net/lists/listinfo/libmesh-users
> >  
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
> 

Re: [Libmesh-users] hp elements

[Benjamin S. K. <be...@cf...>]

Thanks, Daniel, for that complete overview!

As Daniel said, right now (non-infinite) finite elements are defined by 
an order (p) and a family.  The order simply defines the polynomial 
degree that is used for the approximation space, and the family defines 
the type of shape functions that are used.  Right now both are constant 
for the entire mesh.

Unless someone has a good reason I haven't thought of, I see no need to 
support variable *families*.  That is, if you want to use hierarchic 
shape functions, you will use hierarchic shape functions on all 
elements.  This will greatly simplify matters...  Can you imagine what a 
pain it would be to handle solution projection in an efficient manner 
when there may be h,p, *and* family changes going on??

However, the constant p restriction is probably the one you want 
removed, and the good news is that it shouldn't be that hard.  There are 
just a few things that need to happen:

1.)  each DofObject (and, by inheritance, elements) should get an 
order() that defines the approximation order on the element.  The 
order() for nodes is determined by the elements connected to them.   -- easy

2.) The reinit() member in the finite element objects will need to get a 
little smarter & recompute data every time P changes.  This could be 
implemented carefully to be really efficient.  For example, behind the 
scenes we should probably cache element types of various orders so that 
everything does not get recomputed for each element.
 -- tricky

3.) Hanging node constraints must be generalized for all families and 
orders -- not trivial

4.) The solution projection algorithm needs to be generalized -- easy


That's it, as I see it...  there might be some complications for the 
infinite elements that I am not aware of?

-Ben



Daniel Dreyer wrote:

>As already mentioned by Ben, there is no obstacle in the way.
>Actually, here some more details that arose during the implementation
>of the infinite elements (which are actually also p-FEM, but with
>anisotropic p-order, therefore we have _two_ Order enums, namely the
>radial_order and the base_order in FEType, when ENABLE_INFINITE_ELEMENTS
>is active):
>
>
>- momentarily, libmesh already offers p-FEM, but with only constant
>  p-order throughout the mesh.  This order is (currently) determined
>  once for all through the FEType that you have to create in the
>  EquationSystems/SystemBase-child context, when you say add_variable().
>  (note that there is also the simplified variant of add_variable()
>   which only takes an order, and assumes LAGRANGE as family, which
>   only goes up to p=2, use instead e.g. HIERARCHIC).
>
>  In the FEType, you say what order = p you want.  This information is
>  then broadcasted to all objects that may handle a degree of freedom:
>  The DofObject.  Each DofObject may hold _multiple_ components per
>  dof...
>
>  E.g. you have an EDGE3, but you want to use p=3.  Then you have
>  4 dof:
>         o----o----o
>  dof:   0   2,3   1
>  node:  0    2    1
>
>  This is also the numbering scheme in libmesh, first number the nodes
>  that belong to the first-order element, then number the dofs on the
>  second-order-nodes (this is particularly helpful when having a 2nd-order
>  mesh, but you only want to use 1st-order shapes).
>  the DofObject->n_comp() gives then for:
>
>  Node(0) = 1
>  Node(1) = 1
>  Node(2) = 2
>
>  And since both Node and Elem derive from DofObject,
>  you may easily handle bubble shapes etc, consult the HIERARCHIC family.
>
>
>- note that you have to --enable-expensive (or so) in ./configure to
>  get the full support.
>
>
>- GOOD news: the truly tedious work of coding the shapes is already
>  in progress, _several_ new p-FEM families are underway: Steffen and
>  Hendrik have already come a long way implementing them, like the ones
>  that want to orthogonalize the stiffness matrix (integrated Legendre),
>  improved variants (by Adjerid), and two more pretty interesting
>  families that also seem to work well on simplices.
>
>  I suggest you contact Steffen directly for more information.  As far
>  as i know, he almost finished debugging 2D, and wants to proceed to 3D.
>  So perhaps some collab' may be possible.
>
>
>- extending to variable-order-p-FEM is an issue i already thought of
>  in the context of the infinite elements, and also talked to Ben about
>  it.  So, feel free to contact for a more detailed discussion.
>
>Daniel
>
>  
>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: SF.net Giveback Program.
>>Does SourceForge.net help you be more productive?  Does it
>>help you create better code?  SHARE THE LOVE, and help us help
>>YOU!  Click Here: http://sourceforge.net/donate/
>>_______________________________________________
>>Libmesh-users mailing list
>>Lib...@li...
>>https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by OSDN's Audience Survey.
>Help shape OSDN's sites and tell us what you think. Take this
>five minute survey and you could win a $250 Gift Certificate.
>http://www.wrgsurveys.com/2003/osdntech03.php?site=8
>_______________________________________________
>Libmesh-users mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libmesh-users
>  
>

Re: [Libmesh-devel] Re: [Libmesh-users] Fwd: Re: Maybe a bug in libpetsc-2.1.6, I'm sorry

[Benjamin S. K. <be...@cf...>]

I saw the email but did not see the patch...  would you send it again, 
please?  I am interested in what they suggest.

I have been reworking the configure system to better support some of the 
more complicated packages like PETSc and MPI, so I hope that this issue 
will be resolved soon.  I have been away from email lately, so I haven't 
been able to give this much opinion.

Until I see the patch I can't comment on whether the Debian maintainer 
is "right" or "wrong."  It is curious, though, that Debian is the only 
architecture where this is an issue.
PETSc configuration is a difficult issue since they can depend on *so* 
many additional packages.  Unfortunately, their only suggestion for 
mitigating the difficulty is to "use their makefiles," which is not an 
option for a package like libMesh that does not *require* PETSc.

-Ben


Leopold Palomo Avellaneda wrote:

>A Dimecres 03 Desembre 2003 07:16, John Peterson va escriure:
>  
>
>>Please stop spamming the list(s) with this question.  
>>    
>>
>
>I'm sorry. I didn't want to spam the list with this question. We had a problem 
>with the smtp server yesterday (we have had some problems last week, and this 
>too) so I sent a message with a cc to me, but I didn't received it. The last 
>week we lost some messages, so, I post it twice. I'm sorry for the 
>inconvenience.
>
>  
>
>>If someone has an answer for you, I'm sure they will post it.  
>>    
>>
>
>Well, I hoped some opinion. Maybe I was "innocent". I hoped received some kind 
>of "no, the debian mantainer is wrong, because that, that...." or maybe, 
>because we use this in this way, ....
>
>  
>
>>Otherwise,
>>consider the answer to be effectively "no".
>>    
>>
>
>Ok.
>
>Leo
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by OSDN's Audience Survey.
>Help shape OSDN's sites and tell us what you think. Take this
>five minute survey and you could win a $250 Gift Certificate.
>http://www.wrgsurveys.com/2003/osdntech03.php?site=8
>_______________________________________________
>Libmesh-devel mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>  
>

[Libmesh-users] AFTER-HOURS TRADING - Breaking News...chelsi

[Thaddeus G. <dta...@ya...>]

AFTER-HOURS TRADING - BREAKING NEWS

Get Quote - http://quote.money.cnn.com/quote/quote?symbols=3Dhtds

Hard to Treat Diseases Incorporated - HTDS - Announces: Receipt of Tuberci=
n Toxicity Study and Formation of Scientific Advisory Panel - Wednesday De=
cember 3, 8:04 pm ET 

DELRAY BEACH, Fla.--(BUSINESS WIRE)--Dec. 3, 2003--Hard to Treat Diseases =
Incorporated (Pink Sheets: HTDS) announces today that the spokesperson for=
 the independent medical group conducting the testing for HTTD (HTDS) has =
forwarded the formal Testing Results of Tubercin=AE's Toxicity Trials to H=
TTD.

Tubercin of five different concentrations was administered to five groups =
of mice. A pathologist at the University of Oklahoma Health Science Center=
 performed autopsies. The mice were randomized and only the control mouse =
was known to the pathologist, as stated in the cover letter of the Patholo=
gy Report.

The report concludes, "All tissues evaluated, visceral organs and the brai=
n were essentially normal in appearance." "The importance of this report i=
s even better than I expected," stated the spokesperson for the medical gr=
oup. "As the testing continues and if the results are similar to those of =
Chemotherapy and or radiation with no harmful side effects, Tubercin has e=
normous potential for the treatment of cancer and the immune system."

The President and CEO of HTTD, Mr. Colm J. King is in the process of formi=
ng a Scientific Advisory Panel with leading Oncologists and Immunologists =
from prestigious institutions in the U.S. The panel will review the report=
s and results of Tubercin=AE's findings and will report back to Mr. King w=
ith the ongoing reports in layman language for the shareholders.

"We are continuing to receive promising results regarding Tubercin=AE and =
we're looking forward to additional positive results in the near future," =
stated Mr. King. "These tests prove that Tubercin=AE is non-toxic and is t=
he first step on the way to human clinical trials as well as the first pos=
itive breakthrough conducted in the United States with an independent medi=
cal group for Tubercin=AE. 

Operating out of Delray Beach, Florida, Hard to Treat Diseases Incorporate=
d ("HTTD") holds the international marketing rights, except South Korea, t=
o Tubercin=AE, a patented immunostimulant developed for combating Cancer u=
nder medical patent (US Patent 6,274,356). The unique properties unlike ot=
her cancer products are clearly stated in the abstract summary of the pate=
nt... "A carbohydrate complex, which is a mixture of low molecular-weight =
polysaccharides of an arabinomannan structure extracted from Mycobacterium=
 tuberculosis, is highly effective in treating various cancer patients wit=
hout incurring any adverse side effects." 






Statements in this press release that are not historical facts are forward=
-looking statements within the meaning of the Securities Act of 1933, as a=
mended. Those statements include statements regarding the intent, belief o=
r current expectations of the Company and its management. Such statements =
reflect management's current views, are based on certain assumptions and i=
nvolve risks and uncertainties. Actual results, events, or performance may=
 differ materially from the above forward-looking statements due to a numb=
er of important factors, and will be dependent upon a variety of factors, =
including, but not limited to, our ability to obtain additional financing =
and access funds from our existing financing arrangements that will allow =
us to continue our current and future operations and whether demand for ou=
r product and testing service in domestic and international markets will c=
ontinue to expand. The Company undertakes no obligation to publicly update=
 these forward-looking statements to reflect events or circumstances that =
occur after the date hereof or to reflect any change in the Company's expe=
ctations with regard to these forward-looking statements or the occurrence=
 of unanticipated events.



























w kahneliixx  x
zkerunqnd p ojaz ovsjh otsmf vqtdfu r ztb
  ftqs sr

Re: [Libmesh-users] Fwd: Re: Maybe a bug in libpetsc-2.1.6, I'm sorry

[Leopold P. A. <le...@wo...>]

A Dimecres 03 Desembre 2003 07:16, John Peterson va escriure:
> Please stop spamming the list(s) with this question.  

I'm sorry. I didn't want to spam the list with this question. We had a problem 
with the smtp server yesterday (we have had some problems last week, and this 
too) so I sent a message with a cc to me, but I didn't received it. The last 
week we lost some messages, so, I post it twice. I'm sorry for the 
inconvenience.

> If someone has an answer for you, I'm sure they will post it.  

Well, I hoped some opinion. Maybe I was "innocent". I hoped received some kind 
of "no, the debian mantainer is wrong, because that, that...." or maybe, 
because we use this in this way, ....

> Otherwise,
> consider the answer to be effectively "no".

Ok.

Leo

Re: [Libmesh-users] Fwd: Re: Maybe a bug in libpetsc-2.1.6

[John P. <pet...@cf...>]

Leopold Palomo Avellaneda writes:
 > Hi,
 > some days ago I forward a mail from the debian mantainer of the petsc package. 
 > Have you looked it? There are some news about it?

Please stop spamming the list(s) with this question.  If someone
has an answer for you, I'm sure they will post it.  Otherwise,
consider the answer to be effectively "no".

-John

Re: [Libmesh-users] Fwd: Re: Maybe a bug in libpetsc-2.1.6

[Leopold P. A. <le...@wo...>]

Hi,

some days ago I forward a mail from the debian mantainer of the petsc package. 
Have you looked it? There are some news about it?

Best regards,

Leo

[Libmesh-users] Nonlinear solvers

[<an...@tn...>]

John, thank you very much for your answer.=20

Martin L=FCthi writes:
 >  > Which is the best practice to use nonlinear solvers (SNES from Pe=
tsc)
 >  > within libmesh? Is there some generic binding, as there is for th=
e
 >  > SLES solvers?=20

John Peterson writes:
 > At this time there is no nonlinear solver interface for petsc.

Currently I am struggling with the definition of a C callable function
to pass to the SNES solver (called FormFunction in the SNES examples).

The main trouble is to pass the equation system into the FormFunction
and call the linear solver from there. There seems to be a problem
with the C/C++ parameter passing, but not being an expert it is hard
to see what goes wrong.

Any hints/starting points are greatly acknowledged.

Best, Martin

[Libmesh-users] Nonlinear solvers

[John P. <pet...@cf...>]

Martin L=FCthi writes:
 > Which is the best practice to use nonlinear solvers (SNES from Petsc=
)
 > within libmesh? Is there some generic binding, as there is for the
 > SLES solvers?=20
At this time there is no nonlinear solver interface for petsc.
We are in the process of an ongoing design discussion which will
hopefully allow a nonlinear system to be solved in the same
framework as the current linear solvers.  Ben is moving to Houston
right now, and is probably without internet access, otherwise
I'm sure he would have something to post about this.

-John

[Libmesh-users] Nonlinear solvers

[<an...@tn...>]

Hi

Which is the best practice to use nonlinear solvers (SNES from Petsc)
within libmesh? Is there some generic binding, as there is for the
SLES solvers? 

Thanks,

Martin

Re: [Libmesh-users] hp elements

[Daniel D. <d.d...@tu...>]

As already mentioned by Ben, there is no obstacle in the way.
Actually, here some more details that arose during the implementation
of the infinite elements (which are actually also p-FEM, but with
anisotropic p-order, therefore we have _two_ Order enums, namely the
radial_order and the base_order in FEType, when ENABLE_INFINITE_ELEMENTS
is active):


- momentarily, libmesh already offers p-FEM, but with only constant
  p-order throughout the mesh.  This order is (currently) determined
  once for all through the FEType that you have to create in the
  EquationSystems/SystemBase-child context, when you say add_variable().
  (note that there is also the simplified variant of add_variable()
   which only takes an order, and assumes LAGRANGE as family, which
   only goes up to p=2, use instead e.g. HIERARCHIC).

  In the FEType, you say what order = p you want.  This information is
  then broadcasted to all objects that may handle a degree of freedom:
  The DofObject.  Each DofObject may hold _multiple_ components per
  dof...

  E.g. you have an EDGE3, but you want to use p=3.  Then you have
  4 dof:
         o----o----o
  dof:   0   2,3   1
  node:  0    2    1

  This is also the numbering scheme in libmesh, first number the nodes
  that belong to the first-order element, then number the dofs on the
  second-order-nodes (this is particularly helpful when having a 2nd-order
  mesh, but you only want to use 1st-order shapes).
  the DofObject->n_comp() gives then for:

  Node(0) = 1
  Node(1) = 1
  Node(2) = 2

  And since both Node and Elem derive from DofObject,
  you may easily handle bubble shapes etc, consult the HIERARCHIC family.


- note that you have to --enable-expensive (or so) in ./configure to
  get the full support.


- GOOD news: the truly tedious work of coding the shapes is already
  in progress, _several_ new p-FEM families are underway: Steffen and
  Hendrik have already come a long way implementing them, like the ones
  that want to orthogonalize the stiffness matrix (integrated Legendre),
  improved variants (by Adjerid), and two more pretty interesting
  families that also seem to work well on simplices.

  I suggest you contact Steffen directly for more information.  As far
  as i know, he almost finished debugging 2D, and wants to proceed to 3D.
  So perhaps some collab' may be possible.


- extending to variable-order-p-FEM is an issue i already thought of
  in the context of the infinite elements, and also talked to Ben about
  it.  So, feel free to contact for a more detailed discussion.

Daniel

> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>