Closed gforney closed 9 years ago
What's with the guy hanging from the ceiling? And the other guy who's head is in the
floor?
Original issue reported on code.google.com by mcgratta
on 2010-04-09 14:03:04
that never happens when I run it on my computer... but that is wild! Exactly how
would one do that on purpose? Hmmmmm, let me think: The positions that these two
upside down guys are at is where I have two sensors... probably an issue with the
version of somkeview you use is somehow using agent avatars as the sensor avatars -
that's funny :-D
Original issue reported on code.google.com by BlackstoneEngineering
on 2010-04-09 14:27:06
one sensor is measuring w-velocity and the other is measuring CO2 - I'm still
laughing 'cos that just looks so awesome, heh, heh...
Original issue reported on code.google.com by BlackstoneEngineering
on 2010-04-09 14:30:12
I shouldn't be laughing this hard - I'm still recovering from radical lung surgery
(but is JUST soooo funny).
Anyway, the version of smokeview I'm using is 5.4.8 (5220 32-bit) dated 12/3/2009,
and I've edited my SVO file only adding the sidewall sprinklers...
Original issue reported on code.google.com by BlackstoneEngineering
on 2010-04-09 14:36:04
Lucky for me that I don't take care of either Evac or Smokeview. I'll pass this on
to Glenn and Timo.
Glenn, FYI, I'm using SVN 5998 (April 5, 2010), 32 bit Windows version. FDS 5.5.0,
SVN 6004, linux, 32 bit, MPI version. The files are at
~mcgratta/VERIFICATION/TEST_CASES/PorterdaleMill
Original issue reported on code.google.com by mcgratta
on 2010-04-09 14:47:06
I'll take a look at it. Any thing different about the sensor name where the upside
down person is located. Did you say you made some edits to the objects.svo file?
IF
so, could you upload it.
Original issue reported on code.google.com by gforney
on 2010-04-10 22:00:14
Glenn and Kevin,
All I did was copy the info for the upright sprinkler in the svo file and renamed it
sidewall and changes some of the colors for it - that's all folks! Without the
sidewall definition the sprinkler resorts to just a default sprinkler. But this
should have nothing to do with the sensor/upside down agent anomaly... which is
TOTALLY funny but no worries as it doesn't happen with the older version of
smokeview I'm using and that I am satisfied with.
Anyway, look in the fds file for the two sensors - one is the only temp and the
other is the only w-velocity. I think they're like 'sensor6' and 'sensor7' - no
weird name or anything...
Or, better yet we could just delete the two sensors in the fds file and get back to
the main question which seems to be getting sidetracked, and that is the parallel
effeciency calculation aberrations in the out file... but, here is the svo file just
to make things interesting ;-)
Original issue reported on code.google.com by BlackstoneEngineering
on 2010-04-11 02:32:36
The three sensors that are drawn as upside down people do not have a PROP_ID assigned
on the &DEVC line in your FDS input file. The rest of your &DEVC lines do have
PROP_IDs assigned. I use the same code to draw all smokeview objects (objects
defined in objects.svo) whether they be sprinklers, people, tree etc. When a &DEVC
device does not have a PROP defined, I assign one - things must be getting mixed up.
The work around for now (you will need this when you use the new smokeview) is to set
up a property for these three &DEVC lines. Not sure why it works with the earlier
smokeview but now this one.
I'll look at this some more.
Original issue reported on code.google.com by gforney
on 2010-04-11 13:15:17
I found the problem. I was using the same variable for both people drawing and
sensor drawing (when a PROP was not defined). I need to check to make sure the same
error does not occur when I draw particles as smokeview objects.
Original issue reported on code.google.com by gforney
on 2010-04-11 14:21:39
kevin, try your test case with the smokeview I just posted (revision 6041). Should
work now.
Original issue reported on code.google.com by gforney
on 2010-04-11 14:40:08
Glad y'all found the funny bug, heh, heh...
Original issue reported on code.google.com by BlackstoneEngineering
on 2010-04-11 14:52:15
Meanwhile, back to parallel efficiency - I'm only getting about 23 seconds of
simulation a day with my computer setup and this big simulation, much less than the
previous version of the simulation - the main difference is I went from two exhaust
fans with two makeup air holes to eleven exhaust fans and ten makeup air holes. I
guess the extra 'flows' really eat up the processing time, eh?
Original issue reported on code.google.com by BlackstoneEngineering
on 2010-04-11 15:43:01
Hi, I'm back at the office, I skied (cross country) more than 600 km.
The timings: Yes, there seems to be problems with "CPU/step"
when you have evacuation meshes present. The time spent in
the evacuation calculation (after the initialization) you
can see by checking the "EVAC" row at the "CPU Time
Usage, Mesh X" output at the bottom of the CHID.out file.
The "EVA1" etc are some sub times spent in the evac.f90
routines and these do not add up to "EVAC". The sum of "VELO"
and "PRES" times (of the evacuation meshes) gives roughle the
initialization time of the evacuation meshes (the calculation
of the guiding evacuation flow fields). The time "EVAC" for a
mesh is the time the programme uses to move the agents around.
Nota that all the evacuation meshes are run as a single process
if you are doing a MPI calculation. Add up the "EVAC" times of
the main evacuation meshes (these are only printed for main
evacuation meshes, the additional flow fields do not have
any agents) to get the CPU time spent in the evacuation
movement part. Add the "PRES" and "VELO" times of all evacuation
meshes to get the initialization time of the evacuation calculation.
I should try to get the timings (CPU/step) correct for the CHID.out
output.
TimoK
Original issue reported on code.google.com by tkorhon1
on 2010-04-12 10:00:22
Glenn -- the humans appear to be properly located now.
Original issue reported on code.google.com by mcgratta
on 2010-04-12 12:20:01
TimoK: "Yes, there seems to be problems with "CPU/step" when you have evacuation
meshes present... ...I should try to get the timings (CPU/step) correct for the
CHID.out output."
Thanks, Timo ~ and wow, skiing 600km - I'm impressed!
BatGirl
PS - so for now as far as doing the "efficiency of the parallel calculation" per the
user manual (since there is no end of the 'filename.out' file yet to do as you
suggest above as the simulation is still running...), it is safe to say I can ignore
the CPU/step for the EVAC meshes (since their Total CPU time is immensely less that
the Total CPU time for the fire meshes) in doing this calculation?
Original issue reported on code.google.com by BlackstoneEngineering
on 2010-04-12 13:05:36
Kevin: "Glenn -- the humans appear to be properly located now."
Oh, and they were so funny to look at... party pooper!
Original issue reported on code.google.com by BlackstoneEngineering
on 2010-04-12 13:06:47
> it is safe to say I can ignore the CPU/step for the EVAC meshes
Well, yes, but sometimes it is not so simple. It seems that my
test case (1 fire mesh + some evacuation meshes) does not output
correct CPU/step nor Total CPU. Same is true for a case, where
there are just evacuation meshes. So, for timings you should
just run the fire meshes.
The first idea is to check the ICYC logic in the Fortran source
code. I have ICYC < 0 for the initialization of the evacuation
meshes and the fire calculation always has ICYC >= 0 and there
might somewhere funny things with this. Or then something else is
broken.
Timo
PS. 600 km in 14 days is just about 43 km per day.
Original issue reported on code.google.com by tkorhon1
on 2010-04-12 14:13:40
I noticed a bug in the "CPU/step" timings for the fire meshes
also. The CPU/step values were not calculated correctly for
a case, where there are more than one mesh, even in plain
fire calculation. So, the fire calculation timings were
also wrong: CPU/step and Total CPU were wrong, but the
final timings printed at the bottom lines of the .out file
(CPU Time Usage, Mesh xxx) were correct.
The SVN Revision No. : 6062 has the bug fix:
The T_SUM is now summed inside the NM loop.
before it has its own NM-loop before the
T_PER_STEP(NM) NM-loop (two NM-loops). Now
there is just one NM-loop. This way I had
not to change T_SUM (scalar) to a T_SUM(NM)
array.
DO NM=1,NMESHES
IF (PROCESS(NM)/=MYID) CYCLE
T_SUM = 0._EB
SUM_LOOP: DO I=2,N_TIMERS_DIM
T_SUM = T_SUM + TUSED(I,NM)
ENDDO SUM_LOOP
NECYC = MAX(1,NTCYC(NM)-NCYC(NM))
T_PER_STEP(NM) = (T_SUM-T_ACCUM(NM))/REAL(NECYC,EB)
T_ACCUM(NM) = T_SUM
NCYC(NM) = NTCYC(NM)
ENDDO
I'm planning to correct the Evac-timings also, now the
CPU/Step and Total CPU are too large for evacuation
meshes. The T_SUM loop sums up all the sub timers (see
the sub timers listed at the bottom of the .out file).
For evacuation meshes EVAC includes some of the
timers EVA1, EVA2, and EVA3. So, my plan is to add
an logical array, say L_ACCUM(1:N_TIMERS_DIM), which can be
use with the SUM Fortran function to mask the sum
T_SUM=SUM(TUSED(:,NM), MASK=L_ACCUM). Well, might
need one L_ACCUM for fire meshes and one for evacuation
meshes or something like that.
TimoK
Original issue reported on code.google.com by tkorhon1
on 2010-04-14 09:34:23
Now the version "SVN Revision No. : 6067" has the
CPU/step timings corrected also for the evacuation
meshes. Changed also a little bit the names of the
evacuation mesh timing labels:
Kevin, FYI: The (plain) fire mesh calculation timings
were also broken, see the comment 18 above.
EVAC: time spent in evacuation (some global evacuation
initialization times are not included)
FOR: time spent in the force loop for this mesh
P2P: time spent inside the force loop calculating
agent-agent interactions
MOV: time spent in the move loop for this mesh
Note: the times FOR, P2P, MOV are included in EVAC.
TimoK
Original issue reported on code.google.com by tkorhon1
on 2010-04-14 13:51:08
Timo, thanks. This will be useful as we start timing FDS 5 and 6 calculations.
Original issue reported on code.google.com by mcgratta
on 2010-04-14 14:35:05
I managed to do the evacuation timings such that I did
not need to itroduce any new arrays (see comment 18 and
the plan to introduce L_ACCUM or something like that).
There were already the dimensions: N_TIMERS_DIM,
N_TIMERS_FDS, and N_TIMERS_EVAC. And I had the evac-
timers in a good order, the first one was EVAC and
then came the rest (FOR,P2P,MOV). So I just sum
up to the timer EVAC to get the correct sum
(i.e., N=2,N_TIMERS_EVAC-3). This could be a
nice tactics for other timings also, so put
all "extra timers" to the end, so that these are
not summed up to the total time (they are
included already in some other timer).
(Why to add this comment: Well, to document the
changes made correctly.)
TimoK
Original issue reported on code.google.com by tkorhon1
on 2010-04-15 10:37:36
This is an old fixed issue, so now it is closed.
TimoK
Original issue reported on code.google.com by tkorhon1
on 2011-03-24 15:17:03
Original issue reported on code.google.com by
BlackstoneEngineering
on 2010-04-09 13:31:44