Angled walls
shashank
I know that there are limitations that one can not create Angled or
curved walls.
But, If I wish to do so, how should I go with it?
Like, if suppose i wish to create a hexagonal shaped wall, then
1) How should I decide mesh block size?
2) how should I built the obstructions ?
3) If there are any VENTS on angled walls, how to tackle this?
Please help !
Thank You !!
Kevin
rmcdermo
1) use a third-party software that creates the OBST lines for you
(e.g. PyroSim)
2) write your own script to create the OBST lines, which is what I do
(see fds_input.m in the Files page of this group)
3) wait for FDS 6 which will handle the complex shapes you are
describing
Regarding mesh spacing, this depends on the resolution you want or
need. This can't be answered in general.
Regarding VENTs on angles walls, you should take care to make sure
that your total fluxes are correct. Obviously, you have to account
for the surface normal vector and break the flux up based on the
components of this vector. Set up a simple test case to check this
before getting too complicated. I like to use the MASS_FILE=T option
on DUMP to double check mass fluxes.
On Jan 18, 11:25 pm, shashank <borde.shash...@gmail.com> wrote:
F-Sim.de
7.2.2 Repeated Obstructions: The MULT Namelist Group (Table 15.13) of
he FDS users guide.
Mind usng the parameter SAWTOOH.
Boris
Kevin
develop ideas as to how you can set up your geometry in FDS. It's more
fun than the other methods, too.
Emanuele Gissi
you wrote this:
> 3) wait for FDS 6 which will handle the complex shapes you are
> describing
Randy, could you please explain a little how complex shapes will be
entered in the input file?
This is rather important for making sure that the GUI we are slowly
developing is "future proof".
Thank you in advance.
Emanuele
Pete Muir
--
You received this message because you are subscribed to the Google Groups "FDS and Smokeview Discussions" group.
To post to this group, send email to fds...@googlegroups.com.
To unsubscribe from this group, send email to fds-smv+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fds-smv?hl=en.
rmcdermo
I wish I had a simple answer to your question but really this feature
is still very much in development. We are hoping to have FDS 6
released later this year. But the complex geometry routines will
likely still be in beta development at that point. The core macro-
scale geometry routines (OBST) will remain unchanged. Micro-scale
geometry will be handled by the PART line. We are debating whether to
use this construct also for macro-scale geometric primitives like
ellipsoids, cylinders, etc. At the moment these sorts of objects are
generated with a special GEOM line. This is only functional for
development purposes, but just to give you an idea, you would specify
a sphere simply by
&GEOM ID='baseball'
SHAPE='SPHERE'
XYZ=0,0,0
RADIUS=0.03
VELOCITY(1)=40
OMEGA(2)=20
MATL_ID='rubber'
SURF_ID='rough surface'/
The construct is fairly intuitive and would ultimately handle planes
and polynomial surfaces which might be hard handle with PART. So, I
would say that for your GUI to be "future proof" you should think
about how to handle basic geometric primitives, polynomial surfaces,
and be able to create polyhedral surfaces from a collection of
points. What the input construct for FDS will look like exactly I
cannot say right now, but it will be something like what is shown
above. In the very long run, OBST can obviously be made a subset of
GEOM (or whatever). But the primary focus in development right now is
the fluid-structure momentum transfer; the heat transfer and solid
phase pyrolysis models are not yet functional.
Cheers,
Randy
Emanuele Gissi
Last September I participated to the Blender Conference in Amsterdam,
where I presented our ongoing work on FDS.
The often raised question, posed by 3d experts, was: "Why FDS should
take the burden of reinventing 3d geometry description? Why not using
one of the open, recognized formats for 3d geometry description and
adapt it to FDS needs?"
Well, I must admit that this is tempting. This does *not* mean that we
should abandon the simple rectilinear grid or any other assumption
that FDS have or will have for the sake of geometry.
So, here is a rough, simple proposal:
let's generalize OBST namelist:
&OBST ID='baseball'
XXXX_ID='complex 3d object'
SURF_ID='rubber surface'/
XXXX is a new namelist that describes the 'complex 3d object' geometry
in global coordinates:
(a better name is needed!)
&XXXX ID='complex 3d object'
STL(1)='SOLID TRI'
STL(2)='FACET NORMAL 0.0 0.0 -1.0'
STL(3)='OUTER LOOP'
STL(4)='VERTEX -1.5 -1.5 1.4'
STL(5)='VERTEX 0.0 1.7 1.4'
STL(6)='VERTEX 1.5 -1.5 1.4'
STL(7)='ENDLOOP'
STL(...)='...'
STL(...)='...'
STL(N)='ENDFACET'
STL(N+1)='ENDSOLID TRI' /
In this example, I use the simple ASCII STL format,
http://en.wikipedia.org/wiki/STL_(file_format): an STL file describes
a raw unstructured triangulated surface by the unit normal and
vertices (ordered by the right-hand rule) of the triangles using a
three-dimensional Cartesian coordinate system.
The complexity of generating the XXXX namelist is left to
preprocessors.
FDS should only check that the described object is manifold! But
that's easy to do.
At the end of this web page you find a simple example of a tetrahedron
in ASCII STL:
https://webspace.utexas.edu/reyesr/titanium/stl/stlmarch17.htm
STL is the first format that comes to my mind.
Someone else could probably propose something better, as COLLADA or
STEP.
This solutions:
- maintains backward compatibility: old OBSTs still work, control
logic is still usable as it is.
- do not need development resources for geometry description
(primitives...).
If you think that this is feasible, I could begin to rise specific
funds for this development.
If you don't think so, no problem: I am already an happy FDS user ;-)
Thank you in advance,
Emanuele.
rmcdermo
Thanks very much for this. First, let me make clear that the FDS
developers have no desire to reinvent 3D geometric description and we
are happy to listen to the experts and consider their opinions on
formats. From the links you provided, the STL format seems great for
describing faceted geometry. But it is not clear to me how this
alleviates the need for geometric primitives like spheres. Why would
I want a faceted sphere composed of many vertex points when a single
point and a radius will do? And is exact. My main concern here is
convergence. I do not want to have to recreate my geometry if I
decide to refine my mesh. A guiding principle in development is that
as dx-->0 we want to converge to the exact solution. If dx is also
tied to the vertex spacing of the geometry, this is more work I have
to do if I wanted an exact solution to flow around a sphere or
airfoil, say. This is why I think we need to handle polynomial
surfaces as well as geometric primitives. As a prime example,
consider the periodic channel flow verification test given here
http://www.ercoftac.nl/workshop9/workshop01.html
(see Test Case 9.2)
Please keep in mind that how we get the information into and out of
FDS is a secondary consideration in my mind; I am more worried about
getting the physics right. So, I hope it is understood, but I am not
sure it is, that what we are talking about when we say "handle complex
geometry" is not just another way of getting the geometry into FDS
where "under the hood" we would then go about business as usual and
create Leggo obstacles that conform as closely as possible to the STL-
created geometry (not that this wouldn't be helpful, potentially).
What we do now is an immersed boundary method (IBM) that can exhibit
zeroth-order errors for arbitrary surface shapes (see Fadlun et al.,
J. Comp. Phys., 2000). What we are developing is a second-order IBM
that will allow us to treat curved rough surfaces.
So, I am interested to know if there are standard formats for
primitives and polynomial surfaces. Or feel free to argue that these
are a waste of time, but I would counter by saying that at a minimum
we need these objects for V&V purposes. I agree that STL (or
equivalent) will also be needed for faceted geometry and may be the
most useful addition in practice.
Best,
Randy
> In this example, I use the simple ASCII STL format,http://en.wikipedia.org/wiki/STL_(file_format):an STL file describes
Emanuele Gissi
You are absolutely right that STL is not good for the goal you have:
converging to the exact solution. Sorry for not having understood that
before. I did not mean you were wasting your time, I have deep respect
and gratitude for your work.
But as I wrote, STL format was just an example.
For example, IGES and STEP file formats are used for exact description
of 3d geometries and are widely accepted and documented:
http://ts.nist.gov/standards/iges/
There are also free and open libraries to handle those formats.
But I also think that there are people in this list than can propose
better formats...
I just kindly propose to use a standardized language for geometry
description, and not to invent a new one.
If you agree, I begin a little research on that.
Best regards,
Emanuele.
> > In this example, I use the simple ASCII STL format,http://en.wikipedia.org/wiki/STL_(file_format):anSTL file describes
charlie.thornton
for FDS itself. Exchange formats work well to share geometry between
tools, but at some point the geometry has to be reduced down to
whatever domain-specific constructs are used by the solver. To do
what you propose, the guys at NIST would either have to do that
transformation within FDS or change FDS's solver to work in terms of
the geometry definition given by IGES, STEP, or some other format.
On the other hand, those of us that make GUI tools can support lots of
standard formats, merge them all into a common representation and
write out the specific geometry required by FDS. Users can also see
how their models will be changed as a result of the conversion and
take appropriate defensive steps. This repair process is much more
difficult if you can't intervene between the input format and FDS's
internal representation.
- Charlie
> > > In this example, I use the simple ASCII STL format,http://en.wikipedia.org/wiki/STL_(file_format):anSTLfile describes
Kevin
to be able to talk about "standard" formats for 3-D representations of
complex geometries. Are all those CAD developers singing the same
tune? I can almost guarantee you that if we implemented a particular
format, that format would become obsolete tomorrow. Some of you early
FDS users might remember when Smokeview rendered gif images. I
predicted back in the 1990s that cell phones were just a fad. When I
was in college, a computer science majoring friend of mine recommended
that I take Pascal programming (and I actually did). The important
lesson in all this is flexibility -- you never want to lock yourself
into anything. Even if Fortran became obsolete tomorrow we could
convert FDS into C in a matter of minutes (well, maybe hours). Anybody
with any skill at scripting can write a short routine to take some 3-D
representation of a solid and convert it into the FDS input format.
The only requirement ought to be that the representation of the
geometry be some form of readable text. We would not want to be in a
position of decoding binary files.
On Jan 22, 12:11 pm, "charlie.thornton" <charlie.thorn...@gmail.com>
wrote:
> > > > --http://www.emanuelegissi.eu- Hide quoted text -
>
> - Show quoted text -
Fabian Braennstroem
I am a bit more experienced in OpenFOAM and its meshing approach. So it
might be, that do not get the issue with STL ...
OpenFOAM's meshing tool 'snappyHexMesh' uses the ascii STL format as a
base as well. Using STL fits well to the CATIA world as well.
I do not want to explain all details, so I would like to point to this link:
http://www.openfoam.com/docs/user/snappyHexMesh.php
For FDS not all features are needed as it would be enough to go up to
chapter '5.4.5 Cell splitting in specified regions'. Then one could
have a cartesian mesh based on the STL geometry with any refinement
undependant of the vertex position of the STL file.
If one would have a simple function, which reads all vertices of the new
volume mesh and creates for each cell-face an OBST, than it could be a
quite powerful and simple approach to get complex geometries into FDS.
Btw the mesher runs in parallel as well.
Best Regards!
Fabian
Ken
that NIST is doing a pretty good job of refining an analytical model
that focuses on getting the physics right. It sacrifices some model
accuracy and utility, but still in general gets the basic physical
parameters correct. It seems to me that in order to keep this focus,
the model parameters must be defined by FDS. Therefore, any
translation software must convert to what FDS understands. If NIST is
going to venture into geometry definition, this may create
complications that could detract from core mission.
On Jan 22, 11:13 am, Fabian Braennstroem <f.braennstr...@gmx.de>
wrote:
> >> In this example, I use the simple ASCII STL format,http://en.wikipedia.org/wiki/STL_(file_format):anSTL file describes
> >> a raw unstructured triangulated surface by the unit normal and
> >> vertices (ordered by the right-hand rule) of the triangles using a
> >> three-dimensional Cartesian coordinate system.
>
> >> The complexity of generating the XXXX namelist is left to
> >> preprocessors.
> >> FDS should only check that the described object is manifold! But
> >> that's easy to do.
>
> >> At the end of this web page you find a simple example of a tetrahedron
> >> in ASCII STL:https://webspace.utexas.edu/reyesr/titanium/stl/stlmarch17.htm
>
> >> STL is the first format that comes to my mind.
> >> Someone else could probably propose something better, as COLLADA or
> >> STEP.
>
> >> This solutions:
> >> - maintains backward compatibility: old OBSTs still work, control
> >> logic is still usable as it is.
> >> - do not need development resources for geometry description
> >> (primitives...).
>
> >> If you think that this is feasible, I could begin to rise specific
> >> funds for this development.
> >> If you don't think so, no problem: I am already an happy FDS user ;-)
>
> >> Thank you in advance,
> >> Emanuele.
>