On Wed, 1 Apr 2015, grandrabbit wrote:
The build runs fine. Thanks! Now GRINS can also be built on that.
Thanks for the update!
BTW, there're always warning like
In file included from /usr/lib/openmpi/include/mpi.h:253:0,
from ./include/libmesh/libmesh_common.h:53,
esh, not the package itself.
Many thanks,
Zhenyu
------ Original --
From: "Roy Stogner";;
Date: Apr 1, 2015
To: "grandrabbit";
Cc: "libmesh-users";
Subject: Re: [Libmesh-users] How to properly call ParsedFunction
On Tue, 31 Mar 2015,
On Tue, 31 Mar 2015, Roy Stogner wrote:
> I'm also running Ubuntu 14.10, but with a custom PETSc build. Let me
> try installing libpetsc3.4.2-dev (you're using the version from the
> default repos, I assume?) and see if I can replicate the problem.
For me, https://github.com/libMesh/libmesh/pul
On Tue, 31 Mar 2015, grandrabbit wrote:
> As I can undertand now, the usage of ParsedFunction is conditional,
Yes.
> depending on if the boundary condition will be applied on a single variable or
> a variable group.
Not quite. It depends on what the index is of the variable you want
to apply
On Tue, 31 Mar 2015, grandrabbit wrote:
Here are the output of configure. The screen copy is in configure.out
Ubuntu 14.10
libpetsc3.4.2-dev
openmpi 1.6.5-8
export PETSC_DIR=/usr/lib/petsc
Thanks for all the info!
There's definitely something wrong with the PETSc MPI autodetection,
as
>&1 | tee configure.out
Zhenyu
-- Original --
From: "Roy Stogner";;
Date: Mar 31, 2015
To: "grandrabbit";
Subject: Re: [Libmesh-users] How to properly call ParsedFunction
On Tue, 31 Mar 2015, grandrabbit wrote:
> I tried to
Dear Roy,
I think I partly found the key to the assertation failure problem.
As I can undertand now, the usage of ParsedFunction is conditional, depending
on if the boundary condition will be applied on a single variable or a variable
group. This means if two variables u & v are set in one VG,
On Mon, 30 Mar 2015, Roy Stogner wrote:
>
> On Sun, 29 Mar 2015, grandrabbit wrote:
>
>>boundary_id_type id;
>>std::vector var_only(1,0);
>>FunctionBase *f=nullptr;
>> ...
>>id=1; //inlet
>>bid.clear();
>>bid.insert(id);
>>var_only[0]=0;//u
>>bcfunctype=string("
On Sun, 29 Mar 2015, grandrabbit wrote:
>boundary_id_type id;
>std::vector var_only(1,0);
>FunctionBase *f=nullptr;
> ...
>id=1; //inlet
>bid.clear();
>bid.insert(id);
>var_only[0]=0;//u
>bcfunctype=string("expr");
>bcfuncstring=string("y*(1-y)");
>f=new_
BTW,
Here I used GmshIO to read the .msh file of version 2.2.
By default gmsh count $PhysicalNames from 1. This is also inherited by
GmshIO::read_mesh(..).
I guess inside ParsedFunction it is assumed the user given boundary_id_type
should start from zero, right?
If so, there may be incompatibil
Dear Libmesher,
ParsedFunction was shown in quite limited examples, such as adjoint_ex5 (but
never called by default there).
Now I called it for applying Dirihclet BC in my codes as follows.
std::string bcfuncstring,bcfunctype;
std::set bid;
boundary_id_type id;
std::vector var_o
11 matches
Mail list logo