I have another question. In order to bypass the subdomain ID problem, I ran
ex10 using my own mesh, made only with TRI6 elements, getting one ExodusII
file at each timestep, but I can't find a way to visualize the simulation as
a whole, at least not with paraview, specifying time steps just didn't
On Mon, Mar 15, 2010 at 12:09 PM, John Peterson
wrote:
>
> I'm not certain if the attributes are per-element, looking at the
> Exodus API now to check on that.
Yes, actually their documentation on sf.net is excellent. This should
be totally do-able. num_attr is the number of attributes *per
ele
On Mon, 15 Mar 2010, John Peterson wrote:
> Mesh generators don't have to write anything extra. If there are no
> attributes, libmesh doesn't assign any particular value to subdomain
> IDs, or it assigns the block id, at your discretion.
I'd say read in the block id by default if we encounter a
On Mon, Mar 15, 2010 at 11:58 AM, Derek Gaston wrote:
> The problem with this is compatibility with existing mesh generators
> like Cubit... Might be tricky to get them to write the correct
> attribute as the subdomain ID.
Mesh generators don't have to write anything extra. If there are no
attri
The problem with this is compatibility with existing mesh generators
like Cubit... Might be tricky to get them to write the correct
attribute as the subdomain ID.
Derek
Sent from my iPhone
On Mar 15, 2010, at 11:49 AM, John Peterson wrote:
> On Mon, Mar 15, 2010 at 11:44 AM, Kirk, Benjamin (JS
Roy Stogner wrote:
>
> On Sat, 13 Mar 2010, David Knezevic wrote:
>
>> I realized that I hadn't added code for writing/reading SCALAR variables
>> in system_io.C, so I just checked in some changes that fix that. In the
>> process, I noticed that it looks like the if(read_additional_data) block
>>
On Sat, 13 Mar 2010, David Knezevic wrote:
> I realized that I hadn't added code for writing/reading SCALAR variables
> in system_io.C, so I just checked in some changes that fix that. In the
> process, I noticed that it looks like the if(read_additional_data) block
> in System::read_parallel_dat
On Mon, Mar 15, 2010 at 8:28 AM, Cody Permann wrote:
> Do any of the libMesh developers actually "install" Petsc-3.0? That is, does
> anybody in this group run "make install" after successfully building Petsc?
> The reason I ask is that I typically do install Petsc on our shared cluster
> sys
Cody Permann wrote:
> Do any of the libMesh developers actually "install" Petsc-3.0? That is, does
> anybody in this group run "make install" after successfully building Petsc?
> The reason I ask is that I typically do install Petsc on our shared cluster
> systems to keep the source and the co
Do any of the libMesh developers actually "install" Petsc-3.0? That is, does
anybody in this group run "make install" after successfully building Petsc?
The reason I ask is that I typically do install Petsc on our shared cluster
systems to keep the source and the compiled libraries separate fo
10 matches
Mail list logo
