As usual things happen to be more complicated than I thought. First of
all the
data are cell-centered i.e. connection dependent and second, the model
has its own "invalid positions" that define the computational domain
into the computational grid. That's why it seems to me it will be
simpler to switch to data explorer native format while I am still at
the beginning of the work. I compiled the following dx file:
-----------------------------------------------------------------
#K direction is cyclic
object "position list" class array type float rank 1 shape 3 items
(I+1)*(J+1)*K data follows
x1 y1 z1
x1 y1 z2
...
# Irregular positions regular connections
object "connection list" class gridconnections counts I+1 J+1 K
# These points mark the computational domain and must be excluded.
object "invalid list" class array type int rank 0 items #invalid_points
data follows
n1 n2 ...
attribute "dep" string "positions"
# Surface patch 1 in I direction
object "I surface 1" class array type int rank 0 itmes #I_surf_1 data
follows
si1, si2, ...
attribute "dep" string "positions"
attribute "boundary_point" int 1
attribute "bc_type" int 7
... # Surface patch 37 in K direction object "K surface 37" class array
type int rank 0 itmes #K_surf_37 data follows
sk1, sk2, ...
attribute "dep" string "positions"
attribute "boundary_point" int 1
attribute "bc_type" int -3
#K direction is cyclic
object "Pressure" class array type float rank 0 items I*J*K data follows
P(x1,y1,z1), P(x1,y1,z2), ...
attribute "dep" string "connections"
object "myfield" class field
component "positions" value "position list"
component "connections" value "connection list"
component "data" value "Pressure"
component "invalid positions" value "invalid list"
component "surface1" value "I surface 1"
...
component "surface127" value "K surface 37"
end
-----------------------------------------------------------------
Now I hope that the "boundary_point" property will separate the
boundary from volume points and the "bc_type" property will distinguish
between different type of boundary conditions. Do I need more attributes
or do I miss some?
I will highly appreciate your comments.
Thanks,
Ted
Chris Pelkie wrote:
>
> >Ok, "invalid positions" will separate the boundary points from the
> >volume points but in respect to the boundary conditions the boundary
> >points are not equivalent. Is it possible to mark the boundary points
> >with a tag/property that specify the type of boundary conditions
> >imposed on the surface this point belongs?
> >
> >Thanks for your comments,
> >Ted
> >
>
> Sure, just create multiple different components each carrying a
> particular type of tag/property and attached in a one-to-one
> correspondence to each and every position (including interior
> positions because you have to retain the same structure for each
> component attached to a field).
>
> Of course, the interior points don't have a tag, so make it either a
> bogus number like -99 or something to preserve the presumed numeric
> nature of the tag elements. If they are strings, then use "NA" or
> something. The invalid positions knock these out anyway when you go
> to display the tags (so only the boundary tags show up). That's why I
> proposed invalids.
>
> So you have something like:
>
> x, y, z, data1, data2, tag1, tag2, invalid
>
> tuple for each and every point in the data set.
> data1, data2,... are the various data values you measured (temp,
> pressure, etc.) and can be scalar or vector as desired. tag1, tag2,
> .... are various properties. Each column must have consistent type,
> but as mentioned, tag1 could be numeric and tag2 string. invalid is
> the invalid marker already discussed.
>
> If you think of the positions as the base array that "carries" all
> the other components, then imagine laying a sheet of data over these
> positions. This sheet must have a data entry to correspond with every
> position (position-dependent data). Then, the invalids sheet also has
> a value for every position, but the way DX utilizes this sheet is to
> knock holes out where invalids are 01. This takes out the underlying
> position and all associated data/tags/etc with that position, either
> permanently (if you cull) or temporarily (treating it as a 'bandpass'
> filter if you like).
>
> If David's book doesn't answer all your questions, my company does do
> DX consulting for agencies like yours. (:-)
>
> Chris Pelkie
> Vice President/Scientific Visualization Producer
> Conceptual Reality Presentations, Inc.
> 30 West Meadow Drive
> Ithaca, NY 14850
> [EMAIL PROTECTED]
--
Ted Sariyski
Combustion Research and Flow Technology, Inc.
174 North Main Street
Building 3, P.O.Box 1150
Dublin, PA 18917
Tel: (215) 249-9780
Fax: (215) 249-9796
[EMAIL PROTECTED]
[EMAIL PROTECTED]
