a C++ Parser for NASTRAN card

Discussion in 'C++' started by arnuld, Feb 27, 2008.

  1. arnuld

    arnuld Guest

    on Jul 16th, 2007, Erik Wikström gave me this exercise for starting
    with real-life C++ code:


    -------------------------------------------
    So you basically want a proposal for a project which does not require
    the usage of third party libraries and which is not to difficult.

    I've got one for you, build a parser for a subset of the NASTRAN card
    format, the format is as follows, each line is divided into columns of
    8 character each and there are 6 columns per row (totalling 48 chars/row).

    There are two kinds of records of interest for you, the first type
    represents a point in space and has the word "GRID" written in the first
    column, the second column is the ID of the point, the third column is
    empty while the fourth, fifth, and sixth is the X, Y, and Z coordinates,
    respectively, of the point. An example row:

    GRID 1209 0000.0000008.0000010.000

    This represents the point (0,9,10) in 3D space.

    A note on exponents: When writing numbers as exponents we usually write
    1.23e4 or 9.87e-6, in the files they skip the 'e' so those two numbers
    would be 1.23+4 and 9.87-6 respectively.


    The second type of record of interest represents a triangle and contains
    information about which points are the corners of the triangle and which
    object it belongs to. The format is as follows: First column contains
    the word "CTRIA3", second column is the ID of the triangle, third the ID
    of the object the triangle belongs to and the fourth to sixth columns
    contains an ID of a point which makes out the corners of the triangle.

    CTRIA3 0117 11 1198 1209 1210

    This is triangle nr 117, belonging to object 11, its corners are located
    at the points 1198, 1209, and 1210.

    Construct a program which reads such a file and constructs a data-
    structure containing information about what objects are in the model,
    and for each objects have a list of all the triangles that makes up the
    object. For each triangle store information about its corners, its
    area, its centre (mass centre will do), and surface normal (assume
    clockwise ordering of the corners). If you want an extra challenge also
    make a list of all neighbours of the triangles, that is other triangles
    that share shares an edge with it (remember that it does not have to be 3,
    it can be less).

    Some of the data will require some linear algebra to get, I hope you've
    had a course on the subject, if not you might want to skip some of it.
    Also comp.graphics.algorithms, alt.math, and sci.math might be helpful.


    OK, so what is all this you might ask, and why should you do it? While
    it's might not the most exiting assignment in the world (and will be
    totally useless to you) it is a "real" project. What I described above
    specifies the parser used by a program I've written that performs
    simulations of heat transfer used by the automotive industry.

    It really is not a very complicated task, there are two important
    pieces, the first is to correctly read the data from the file which
    will require some fiddling with IO-streams but you should be familiar with
    the basics by now. The other part is to organise the data you read in,
    start by designing classes representing the "things" in the program, such
    as objects as such.
    --------------------------------

    here is the full list of input: http://dpaste.com/hold/37024/


    Erik said i could write this program usign Classes. I have only one
    idea about this program: I need to put that input into a simple text file
    but then how to read all those things fromthere into different veriables ?
    and from where to start ? and how does

    GRID 1209 0000.0000008.0000010.000

    This represents the point (0,9,10) in 3D space ?

    how he calculated the 3 co-ordinates. I only see 1 co-ordinate and that
    is: 0000.0000008.0000010.000




    --
    http://lispmachine.wordpress.com/
     
    arnuld, Feb 27, 2008
    #1
    1. Advertising

  2. arnuld

    arnuld Guest

    arnuld, Feb 27, 2008
    #2
    1. Advertising

  3. arnuld

    James Kanze Guest

    On Feb 27, 8:40 am, arnuld <> wrote:
    > on Jul 16th, 2007, Erik Wikström gave me this exercise for
    > starting with real-life C++ code:


    > -------------------------------------------
    > So you basically want a proposal for a project which does not
    > require the usage of third party libraries and which is not to
    > difficult.


    > I've got one for you, build a parser for a subset of the
    > NASTRAN card format, the format is as follows, each line is
    > divided into columns of 8 character each and there are 6
    > columns per row (totalling 48 chars/row).


    > There are two kinds of records of interest for you, the first
    > type represents a point in space and has the word "GRID"
    > written in the first column, the second column is the ID of
    > the point, the third column is empty while the fourth, fifth,
    > and sixth is the X, Y, and Z coordinates, respectively, of the
    > point. An example row:


    > GRID 1209 0000.0000008.0000010.000


    > This represents the point (0,9,10) in 3D space.


    That should be (0,8.10), of course. And shades of Fortran,
    there's a subtle tricky bit in there for a beginner: the numeric
    values aren't separated.

    > A note on exponents: When writing numbers as exponents we
    > usually write 1.23e4 or 9.87e-6, in the files they skip the
    > 'e' so those two numbers would be 1.23+4 and 9.87-6
    > respectively.


    Another input conversion problem. (Again, IMHO, not for
    beginners.)

    > The second type of record of interest represents a triangle
    > and contains information about which points are the corners of
    > the triangle and which object it belongs to. The format is as
    > follows: First column contains the word "CTRIA3", second
    > column is the ID of the triangle, third the ID of the object
    > the triangle belongs to and the fourth to sixth columns
    > contains an ID of a point which makes out the corners of the
    > triangle.


    > CTRIA3 0117 11 1198 1209 1210


    > This is triangle nr 117, belonging to object 11, its corners
    > are located at the points 1198, 1209, and 1210.


    And if I understand the specification above, this could also
    appear as:
    CTRIA3 0117 11000011980000120900001210

    [...]
    > --------------------------------


    > here is the full list of input: http://dpaste.com/hold/37024/


    > Erik said i could write this program usign Classes. I have
    > only one idea about this program: I need to put that input
    > into a simple text file but then how to read all those things
    > fromthere into different veriables ? and from where to start?
    > and how does


    > GRID 1209 0000.0000008.0000010.000


    > This represents the point (0,9,10) in 3D space ?


    Read the specification of the file. Each line is a sequence of
    8 byte fields. If I insert a | between each field, I get:
    GRID | 1209| |0000.000|0008.000|0010.000
    CTRIA3 | 0117| 11| 1198| 1209| 1210

    In other words, the last three fields are "0000.000", "0008.000"
    and "0010.000". In other words, the point (0,8,10). (The 9 is
    probably just a typo.)

    > how he calculated the 3 co-ordinates. I only see 1 co-ordinate
    > and that is: 0000.0000008.0000010.000


    And what kind of value has three decimal points in it?

    The simplest way to handle this sort of input is to read the
    file line by line, chop it up into fields, and then parse each
    field:

    std::string line ;
    std::getline( source, line ) ;
    if ( line.size() !- 64 ) {
    // I think we've got a problem...
    } else {
    std::vector fields ;
    for ( int i = 0 ; i < 6 ; ++ i ) {
    fields.push_back( line.substr( 8 * i, 8 ) ) ;
    }
    }

    (I'd probably actually do this a bit more generically, reading
    the field positions from an array. The principle is the same,
    but the generic solution isn't more difficult, and would allow
    fields of varying length.)

    When you need a numeric value from a field, you use the string
    value to initialize an istringstream, and read from it.

    For the rest---in fact, probably long before you start worrying
    about how to read the file, you should try to define the types
    you'll need to deal with the problem. Two candidates,
    obviously, are Grid and Triangle, but you'll probably find
    others.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Feb 27, 2008
    #3
  4. arnuld

    LR Guest

    arnuld wrote:
    > on Jul 16th, 2007, Erik Wikström gave me this exercise for starting
    > with real-life C++ code:


    This looks like a really great project!



    > CTRIA3 0117 11 1198 1209 1210
    >
    > This is triangle nr 117, belonging to object 11, its corners are located
    > at the points 1198, 1209, and 1210.



    Doesn't 11 denote the real constant set for element 117? Does Nastran
    call this an object?




    >
    > Construct a program which reads such a file and constructs a data-
    > structure containing information about what objects are in the model,
    > and for each objects have a list of all the triangles that makes up the
    > object. For each triangle store information about its corners,


    Angle? Or the point itself? Or the number of the GRID point.

    > its
    > area, its centre (mass centre will do), and surface normal (assume
    > clockwise ordering of the corners).


    The lengths of each side can be useful. It's always nice if these are
    all the close to the same length. There can be problems when one side is
    much smaller than the another.

    I'm not sure that you want to store these things unless you use them
    alot. Having methods that return the information might, might, be
    better. Or not.



    > If you want an extra challenge also
    > make a list of all neighbours of the triangles, that is other triangles
    > that share shares an edge with it (remember that it does not have to be 3,
    > it can be less).


    And it can be more too, right?


    Wouldn't it be useful to provide the real constants, at least thickness
    for the CTRIA3 and density, so we could calculate the volume and mass of
    the model?


    >
    > Some of the data will require some linear algebra to get, I hope you've
    > had a course on the subject, if not you might want to skip some of it.
    > Also comp.graphics.algorithms, alt.math, and sci.math might be helpful.


    You might also want to check out some of the engineering ngs.


    > OK, so what is all this you might ask, and why should you do it? While
    > it's might not the most exiting assignment in the world (and will be
    > totally useless to you) it is a "real" project. What I described above
    > specifies the parser used by a program I've written that performs
    > simulations of heat transfer used by the automotive industry.




    > It really is not a very complicated task, there are two important
    > pieces, the first is to correctly read the data from the file which
    > will require some fiddling with IO-streams but you should be familiar with
    > the basics by now. The other part is to organise the data you read in,
    > start by designing classes representing the "things" in the program, such
    > as objects as such.


    You'll probably find std::map to be extremely useful for this project.


    > --------------------------------
    >
    > here is the full list of input: http://dpaste.com/hold/37024/


    I have a few comments.

    You may want to start with something smaller. Make a file with just a
    few CTRIA3 cards. To begin with make at least one of the dimensions on
    the GRID cards, maybe Z, all zero. This might be easier to debug at first.

    AFAIK, the cards don't have to be in ascending order, and the numbers of
    the grid or elements don't have to be sequential. It might be possible
    for GRID 985 to be followed by 992 for example.

    Remember, the people (your users) who create these files aren't always
    as careful as we have to be. So after you get the basics down you'll
    want to check that the triangles have three unique points.

    $ a comment card. Useful, no?
    $ this is an error!
    CTRIA3 1999 13 1408 1419 1408


    You might also want to check for things like this:

    $
    $ this might be an error. It probably is.
    CTRIA3 1412 13 1408 1419 1407
    CTRIA3 1415 13 1419 1407 1408


    BTW, when you get around to it, and you start to think about how to
    check for these kinds of things, you might want to think about how you'd
    handle other elements, for example, CHEXA which is an eight point solid.


    arnuld, this really does look like a great project. Please let us know
    how it goes.

    LR
     
    LR, Feb 27, 2008
    #4
  5. On 2008-02-27 19:26, LR wrote:
    > arnuld wrote:


    >> CTRIA3 0117 11 1198 1209 1210
    >>
    >> This is triangle nr 117, belonging to object 11, its corners are located
    >> at the points 1198, 1209, and 1210.

    >
    >
    > Doesn't 11 denote the real constant set for element 117? Does Nastran
    > call this an object?


    You might be right, all I know is that (in the models I saw) the number
    indicates a set of triangles that make up one object. I never used
    Nastran itself, the format was used because other applications could all
    understand it.

    >> Construct a program which reads such a file and constructs a data-
    >> structure containing information about what objects are in the model,
    >> and for each objects have a list of all the triangles that makes up the
    >> object. For each triangle store information about its corners,

    >
    > Angle? Or the point itself? Or the number of the GRID point.
    >
    >> its area, its centre (mass centre will do), and surface normal
    >> (assume clockwise ordering of the corners).

    >
    > The lengths of each side can be useful. It's always nice if these are
    > all the close to the same length. There can be problems when one side is
    > much smaller than the another.
    >
    > I'm not sure that you want to store these things unless you use them
    > alot. Having methods that return the information might, might, be
    > better. Or not.


    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.

    >> If you want an extra challenge also
    >> make a list of all neighbours of the triangles, that is other triangles
    >> that share shares an edge with it (remember that it does not have to be 3,
    >> it can be less).

    >
    > And it can be more too, right?


    Only with weird geometries.

    > Wouldn't it be useful to provide the real constants, at least thickness
    > for the CTRIA3 and density, so we could calculate the volume and mass of
    > the model?


    I never had this data available, but I suppose it is just a matter of
    creating a new file that maps from what I called object number to some
    extra data.

    --
    Erik Wikström
     
    Erik Wikström, Feb 27, 2008
    #5
  6. arnuld

    LR Guest

    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.


    >>> If you want an extra challenge also
    >>> make a list of all neighbours of the triangles, that is other triangles
    >>> that share shares an edge with it (remember that it does not have to be 3,
    >>> it can be less).

    >> And it can be more too, right?

    >
    > Only with weird geometries.


    I don't see what would be weird about that. Plenty of things might have
    geometries that look like or could map to a T or X cross sections.


    LR
     
    LR, Feb 28, 2008
    #6
  7. In message
    <>,
    James Kanze <> writes
    >On Feb 27, 8:40 am, arnuld <> wrote:

    [...]

    >> how he calculated the 3 co-ordinates. I only see 1 co-ordinate
    >> and that is: 0000.0000008.0000010.000

    >
    >And what kind of value has three decimal points in it?


    An IP address? Every structure needs connectivity ;-)

    --
    Richard Herring
     
    Richard Herring, Feb 28, 2008
    #7
  8. arnuld

    James Kanze Guest

    On Feb 28, 11:42 am, Richard Herring <junk@[127.0.0.1]> wrote:
    > In message
    > <>,
    > James Kanze <> writes>On Feb 27, 8:40 am,
    > arnuld <> wrote:


    > [...]


    > >> how he calculated the 3 co-ordinates. I only see 1 co-ordinate
    > >> and that is: 0000.0000008.0000010.000


    > >And what kind of value has three decimal points in it?


    > An IP address? Every structure needs connectivity ;-)


    :). Yes. (Although technically, in an IP address, I don't
    think that one can call them *decimal* points.) Although I've
    never seen an IP address in quite that format (but the number of
    dots is correct!).

    More generally, yes. Given the precedence of domain names, I
    tend to use dot's to separate levels in any hierarchy. It's as
    good a convention as anything else.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Feb 28, 2008
    #8
  9. arnuld

    James Kanze Guest

    On Feb 28, 1:17 am, LR <> 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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Feb 28, 2008
    #9
  10. On 2008-02-28 01:17, LR wrote:
    > Erik Wikström wrote:
    >> On 2008-02-27 19:26, LR wrote:
    >>> arnuld wrote:


    >>>> If you want an extra challenge also
    >>>> make a list of all neighbours of the triangles, that is other triangles
    >>>> that share shares an edge with it (remember that it does not have to be 3,
    >>>> it can be less).
    >>> And it can be more too, right?

    >>
    >> Only with weird geometries.

    >
    > I don't see what would be weird about that. Plenty of things might have
    > geometries that look like or could map to a T or X cross sections.


    Mmm, yes. I only saw the data used to describe surfaces, they never had
    any depth. But if we assume that they do then it would make sense.

    --
    Erik Wikström
     
    Erik Wikström, Feb 28, 2008
    #10
  11. arnuld

    LR Guest

    James Kanze wrote:
    > On Feb 28, 1:17 am, LR <> 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
     
    LR, Feb 28, 2008
    #11
  12. arnuld

    Craig Scott Guest

    On Feb 28, 10:41 pm, James Kanze <> wrote:
    > On Feb 28, 1:17 am, LR <> 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
     
    Craig Scott, Feb 28, 2008
    #12
  13. arnuld

    Craig Scott Guest

    On Feb 29, 7:54 am, Craig Scott <> 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
     
    Craig Scott, Feb 28, 2008
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bernd Oninger
    Replies:
    0
    Views:
    794
    Bernd Oninger
    Jun 9, 2004
  2. ZOCOR

    XML Parser VS HTML Parser

    ZOCOR, Oct 3, 2004, in forum: Java
    Replies:
    11
    Views:
    849
    Paul King
    Oct 5, 2004
  3. Bernd Oninger
    Replies:
    0
    Views:
    844
    Bernd Oninger
    Jun 9, 2004
  4. Joel Hedlund
    Replies:
    2
    Views:
    559
    Joel Hedlund
    Nov 11, 2006
  5. Joel Hedlund
    Replies:
    0
    Views:
    329
    Joel Hedlund
    Nov 11, 2006
Loading...

Share This Page