I started to create a page in May, but decided that our discussion
group is probably not the best place to put it.
-Bryan
--
Bryan Klein
bryan...@nist.gov
National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8663
Gaithersburg MD 20899
Phone: 301 975 5171
Fax: 301 975 4052
--
Glenn Forney
National Institute of Standards and Technology
100 Bureau Drive, Stop 8663
Gaithersburg MD 20899-8663
Telephone: (301) 975 2313
FAX: (301) 975 4052
Pre-decisional and sensitive information. Not for attribution, distribution, or reproduction.
The executable has been used on 64bit Windows XP.
In some individual case, it was a bit faster and used a little bit less
memory
than running the same case with 32bit code under 64bit windows.
Simo
I am glad at the same time that you are aware that some people think
that all woods are the same and use them inappropriately also.
I fully agree that more cooperation from other countries and research
institutions would help in the objective of developing a database.
However, in the meantime, I would love to see a lean database of key
materials. Those materials would be materials that we be best
documented and least questionable. This database would be also a
"guide" database from which users would, at their discretion and risk,
extrapolate or interpolate to "mimic" behaviors of materials they would
be interested in. Naturally, an even more glaring disclaimer would need
to preface the document, as well as locating a reminder disclaimer on
every page as a header or a footer.
I know my suggestion is not the ideal database that everyone wants to
see, but it is a compromise.
Thanks for your consideration.
Daniel
-----Original Message-----
From: fds...@googlegroups.com [mailto:fds...@googlegroups.com] On
I have the Dual Quad-Core Mac Pro with 16GB of RAM, this is a 64bit platform.
After I compile a working 64 bit version of FDS (including the MPI
version), I will run the scaling test example setting the number of
meshes and grid resolutions to exceed the 4GB threshold of 32bit
systems. So far I have not seen a significant speedup in the
processing speed. 3GHz is 3GHz no matter the number of bits, in fact I
have a feeling that there is a little bit of cache overhead in the
chip with 64 bit FDS that makes it slightly slower than the 32 bit
version I am running. I am also building the 64bit version with
multiple code paths depending on the chipset (SSE, SSE2, etc.) This
could also create some slight overhead than a version compiled for my
machine only.
All this to say, I am working on it here too and will report back my
findings. Now to get MPICH2 to build in 64 bit in Leopard. Ugh...
no joy so far. It is not all smug and quirky Mac vs. PC comments in
OSXland today... Come on kitty-cat, don't fail me now!
-Bryan
--
Bryan Klein
bryan...@nist.gov
National Institute of Standards and Technology
Dragonit wrote:
> We are currently experimenting with a 64bit environment -
> FDS5(compiled by Poretti Martino ) Parallel Version.
> plus the MPICH 64 bit and a Win 2003 Server. on a Dual Quad
> processors with 32GB of RAM
>
> will be happy to test benchmark cases and will report tests result as
> soon we have some
>
>
> 2007/12/12, Glenn Forney <glenn....@nist.gov
> <mailto:glenn....@nist.gov>>:
However, I believe that if users choose to ignore disclaimers and
limitations of models or databases, it is their responsibility to accept
consequences. Historically, they were many abuses by users of what fire
models were designed to do. I further contend that if engineering or
scientific communities stopped using models because of the relatively
few abuses, then we would probably loose faith, interest, and support in
performance fire safety, hence, that would spell out the slow death of
fire engineering progress.
I believe that it is reasonable to, using your example of steel, share
at least 3 types of steel materials properties which would reflect 3
general categories, while stressing, as a disclaimer, that any variation
of the specified 3 materials would automatically imply that the user is
on his/her own as to the professional risk they are taking.
Otherwise, if we entertain creating a comprehensive database, we will be
always behind the "8 ball" as new alloys are created practically
everyday.
Please do not take offense by my point of view, I am simply and honestly
sharing with the group a compromising approach.
Thanks, Daniel
The validation report, which is coming out soon, contains a large number
of full
scale fire test simulations, demonstrating the accuracy of the code in
such applications.
In these simulations, the material properties have usually been
specified by the
experimentalists.
I don't understand your last comment on every simulation being
different.
Interpretation of test results was the question.
Simo
> With "every simulation is different" I ment that if someone
> interpreted the parameter not like you (because no standart),
> you will have different properties and so their is (perhaps)
> no comparable between different simulations.
>
> I not want to say, that fds is not valid. You showed this in
> (real) tests (and will these show in the validation report).
I didn't think you said that. I just explained how the current
V&V efforcts have been made.
Regards,
Simo
Unless, you feel that the same questions that you posted on the new
group cannot be asked here.
If that is the case, then we have problems that need to be addressed,
since this would not be good.
You are free and welcome to maintain these lines of discussion and
even create pages within the FDS group to consolidate information
related to the topic of turning raw materials into validated FDS
material property data. Coordinated efforts are necessary to move
forward on this topic.
Creating another group is an obvious sign that you think the issue is
important, but in my opinion, it does not help with the solution.
Maybe begin the work to answer the questions on your new group and
post the results within the existing information resources (fds-smv
group) and you will begin to more effectively contribute to solving
this problem.
What is missing from the fds-smv group that made you feel that
creating another group is the solution?
What can we do to help in your opinion?
Feedback is always welcome.
Best Regards,
Bryan