On Dec 10, 2008, at 3:07 PM, Benjamin Kirk wrote:
> Because if you try adding quads to a dim=3 mesh it will fail.
You're right.
> And because 2D mesh which is a surface in 3D needs to be written as
> a 3D
> exodusII mesh, right?
This I don't know.
> And what is the problem reading an exodusI
So really, unless there is a good reason... I think we should revert back
to:
num_dim = mesh.mesh_dimension();
I still just can't see why it was changed. If you want a 2D mesh in 3D...
wouldn't you declare the Mesh object with dim=3?
Derek
On Wed, Dec 10, 2008 at 12:50 PM, Derek Gaston <[EMAIL
Ok - maybe I don't understand... but why was this a bug in the first place?
To me... if you declare a Mesh object with dim=2 and you read an Exodus
file with dim=2... then when you output it you should expect to get dim=2?
Why would you want to always get LIBMESH_DIM? I shouldn't have to
recompi
On Wed, 10 Dec 2008, Roy Stogner wrote:
> Even after we come up with a new API, there's probably other places in
> mesh/*.C where the "one id per side" assumption is being made. It was
> in xdr_io.C that I hit that bug, for instance:
> XdrIO::write_serialized_bcs() gets called with
> n_bcs==n_b
On Dec 10, 2008, at 12:04 PM, Roy Stogner wrote:
> Hopefully I'm just being overly paranoid, though; do Exodus/etc.
> support multiple IDs per side?
The answer is yes: Exodus does support more than one side id per
side. In reality it's not a side ID per say... but rather lists of
sides... or
On Wed, 10 Dec 2008, Roy Stogner wrote:
> We'd still need to make some major changes to make that work, though:
Oh, and by "major changes" I may even mean "impossible changes".
Obviously our XDR/XDA-based format will handle multiple IDs per side
just fine after a bugfix or two in the read/write
On Wed, 10 Dec 2008, Benjamin Kirk wrote:
> That actually was the original intent - to allow multiple BC ids to be
> assigned to the same face. You could then apply 'no-slip' and 'isothermal'
> separately, or no-slip could be the combination of
> u-symmetry,v-symmetry,w-symmetry, resulting in (u
> We've currently got side boundary ids stored in a:
>
> std::multimapstd::pair >
> _boundary_side_id;
>
> Wouldn't it make more sense to use:
>
> std::map, short int>?
>
> The side number (the unsigned short int) is an input to the
We've currently got side boundary ids stored in a:
std::multimap >
_boundary_side_id;
Wouldn't it make more sense to use:
std::map, short int>?
The side number (the unsigned short int) is an input to the map, not
an output. And, more important to
> Ok - something about the way this was "fixed" has broken stuff for me. If I
> now read a 2D Exodus mesh (using a Mesh created with dim=2) and then write the
> solution out it comes out having a dimension of _3_.
>
> To see this you can just run the attached exodus file (generated using Cub
Ok - something about the way this was "fixed" has broken stuff for me. If I
now read a 2D Exodus mesh (using a Mesh created with dim=2) and then write
the solution out it comes out having a dimension of _3_.
To see this you can just run the attached exodus file (generated using
Cubit) through
11 matches
Mail list logo
