«

James Kanze wrote:
> On Feb 28, 1:17 am, LR <lr...@superlink.net> wrote:
>> Erik Wikström wrote:
>>> On 2008-02-27 19:26, LR wrote:
>>>> arnuld wrote:
>>> Depends of course on what you want to do with the
>>> information, I choose those more or less at random since it
>>> adds some to the project. If you can come up with an idea of
>>> what to do with the data from the file that would of course
>>> make things even better.
>
>> Hmmm... how about constructing a stiffness matrix and...
>
>> Well, maybe these:
>
>> Find the center of mass for the entire model, not just the
>> individual elements.
>
>> Find out if any of the elements are unconnected from the rest
>> of the model.
>
>> Find out if any of the GRID points are unused.
>
>> See if there are any gaps between elements. For example, given
>> line AXB
>> Triangle A B C
>> Triangle A D X
>> Triangle X D B
>
>> Look for GRID points that are so close together they should be
>> eliminated, and write a new valid file.
>
>> Check to see if the sides of the elements are all oriented in
>> the same way relative to their connectivity. That is, suppose
>> you have a geometry that looks like a V in cross section, then
>> you'd want all the normals to be "outside" the V or "inside"
>> the V, but probably not both.
>
>> Allow the user to pick a group of elements and break each
>> triangle into two or three more triangles, generating a new
>> valid file. Extra credit for placing any new GRID points
>> created on smoothed curves.
>
>> Write code that allows you to add two model files together.
>
>> Some of the above implies some interesting uses of std::set,
>> some of it implies some challenges with floating point math.
>
> Most of them imply some very great challenges with floating
> point math.

Yes, you're right, I was indulging my, ahem, talent for understatement.


> Just off hand, the only one I'd be capable of doing
> is finding whether any of the GRID points are unused.

I think there are a few of the others that you could do as well.

What I failed to make clear, is that at least two of the problems are
very difficult, maybe impossible, to solve in the general case.

So some of the problems should be restated to be a small subset of what
I said.

For example, writing code that allows two models to be added together,
perhaps only provide solutions for cases where we will attach the models
together at GRID points that are less than a fixed distance, provided by
the user, from each other.

I think that makes the problem a little more tractable.

I was perhaps a little too optimistic in stating these in such an open
ended way.

In any case, these are problems that shouldn't be tackled until the more
basic work suggested by Eric Wikstrom is completed. And please allow me
to repeat that I think it's a great project.



> And I
> don't consider myself a beginner, nor particularly incompetent.
> Just not a specialist in numeric processing. (I know enough
> about it to know that I don't know enough about it, but that's
> about it.)

I tend to think of myself as a beginner. And I'm certainly not a
specialist in numeric processing either. At least a few of the problems
above have more to do with manipulating sets than with numeric
processing. Something else I'm not a specialist in.



> There are probably problems which could be posed which don't
> require much numeric processing, but I'm sceptical.

I think there are three problems in the group above which require no
numeric processing, because the connections we are concerned with are
logical rather than numeric. IE the possibility of two triangles
'wrongly' intersecting numerically does not concern an FEA solver, even
though we might like to know about it, since it's probably 'wrong'.

The three problems are:
1) Unconnected element. Could be two unconnected groups.
2) Unused GRID point.
3) Gap between triangles.

Three is a little tricky, because there will be some geometries where
this is the right thing to do.


> The input
> is in floating point, to begin with, even something as simple as
> trying to determine whether the file describes a single closed
> solid or not will involve significant analysis of the actual
> floating point arithmetic involved.


A single closed solid? I'm not sure I follow that. But given the nature
of the input, and if I understand what you mean, I think this question,
while somewhat open ended, might boil down to: Do any two triangles
intersect other than sharing one line in common. I don't think this is
insurmountable in a practical sense. But certainly not simple.


LR

On Feb 28, 10:41 pm, James Kanze <james.ka...@gmail.com> wrote:
> On Feb 28, 1:17 am, LR <lr...@superlink.net> wrote:
> > Erik Wikström wrote:
> > > On 2008-02-27 19:26, LR wrote:
> > >> arnuld wrote:
> > > Depends of course on what you want to do with the
> > > information, I choose those more or less at random since it
> > > adds some to the project. If you can come up with an idea of
> > > what to do with the data from the file that would of course
> > > make things even better.
> > Hmmm... how about constructing a stiffness matrix and...
> > Well, maybe these:
> > Find the center of mass for the entire model, not just the
> > individual elements.
> > Find out if any of the elements are unconnected from the rest
> > of the model.
> > Find out if any of the GRID points are unused.
> > See if there are any gaps between elements. For example, given
> > line AXB
> > Triangle A B C
> > Triangle A D X
> > Triangle X D B
> > Look for GRID points that are so close together they should be
> > eliminated, and write a new valid file.
> > Check to see if the sides of the elements are all oriented in
> > the same way relative to their connectivity. That is, suppose
> > you have a geometry that looks like a V in cross section, then
> > you'd want all the normals to be "outside" the V or "inside"
> > the V, but probably not both.
> > Allow the user to pick a group of elements and break each
> > triangle into two or three more triangles, generating a new
> > valid file. Extra credit for placing any new GRID points
> > created on smoothed curves.
> > Write code that allows you to add two model files together.
> > Some of the above implies some interesting uses of std::set,
> > some of it implies some challenges with floating point math.
>
> Most of them imply some very great challenges with floating
> point math. Just off hand, the only one I'd be capable of doing
> is finding whether any of the GRID points are unused. And I
> don't consider myself a beginner, nor particularly incompetent.
> Just not a specialist in numeric processing. (I know enough
> about it to know that I don't know enough about it, but that's
> about it.)
>
> There are probably problems which could be posed which don't
> require much numeric processing, but I'm sceptical. The input
> is in floating point, to begin with, even something as simple as
> trying to determine whether the file describes a single closed
> solid or not will involve significant analysis of the actual
> floating point arithmetic involved.

Hard to pick which post to reply to, so don't take it personally James
that I picked yours.

Having done this and similar things in my current job, I would suggest
that a good thing to consider, even for a beginner, is what effect
will it have on your design if someone later wants to support
different element types other than just CTRIA3? This is a design
question and not something numerically hard, and it gets the person
thinking about how flexible their design is rather than how to solve a
particular one-off problem.

Another useful question to ask is can you find a formal document which
defines the file format? There are lots of different 3D mesh file
formats and plenty of software tries to/must be able to read and write
them. That means ensuring that your own software implements the
standard for the file format properly. For a beginner project such as
the one discussed in this thread, I think it would be sufficient just
to have the person go through the task of finding the document and
confirming some statement or answering some question about it that is
relevant to the task (eg is it possible/allowable to include some kind
of text tag on a GRID statement?). The reason I suggest this task is
that in practice, this is what you have to do to write good quality 3D
mesh readers and writers. It isn't C++, more part of good software
engineering practice.

If you want to get a little more interesting, get your hands on a
really big input file. This will test how well your reader code
scales. Since the CTRIA3 elements refer to GRID entries by ID numbers
that are not necessarily sequential, you've got a number lookup to
perform. How you do that can be really important for performance if
the file is very large.

Other miscellaneous thoughts in no particular order:

What if a GRID is repeated with the same ID? Is that an error?

If I've just concatenated two NASTRAN files and they share common
nodes that should be merged (we did this frequently at one company I
worked for), should I check that nodes with the same ID have the same
data for the rest of the line too?

What if I wanted to assign data to each of the GRID nodes once I'd
read them in? How would I store that in my data structures? Start with
something simple, like storing just one floating point number per
node.

Do I need the normal vector of the CTRIA3 elements? This is easy to
calculate, except that the triangular elements can degenerate into
splinters and have a zero normal vector. This is numerical and might
be outside the areas you want the person to deal with though.

If I wanted to know all the GRID nodes that were inside a given axis-
aligned cube, how could I do that efficiently? Classic computer
science problem, but not necessarily easy. There's a whole class of
problems here....

Nothing beats pictures! Can you find an open source 3D mesh viewer and
re-export your NASTRAN file out into a format that the 3D viewer
supports? A Vtk file format may be worth looking at, and it would
provide an interesting way of using the data read in because its file
format is structured differently to NASTRAN. A useful thing about this
step is that it can be a great way to quickly and easily check if your
reader is reading in the data correctly, since anything you read
incorrectly will frequently show up as a very obvious misplaced node
or element in the 3D scene when you look at it in the viewer.

HTH

--
Computational Modeling, CSIRO (CMIS)
Melbourne, Australia

On Feb 29, 7:54 am, Craig Scott <audiofana...@gmail.com> wrote:
> If I wanted to know all the GRID nodes that were inside a given axis-
> aligned cube, how could I do that efficiently? Classic computer
> science problem, but not necessarily easy. There's a whole class of
> problems here....

Argh! The question I *meant* to pose was, what if I wanted to know all
the GRID nodes within some distance of a point. Was already thinking
about implementation when I wrote the first post.

--
Computational Modeling, CSIRO (CMIS)
Melbourne, Australia