[esp-r] Re: Some bugs in subsys.F ?

Thu May 5 16:06:38 BST 2011

Hi Alex, 

Sorry for the late reply, a bad flu knocked me down for 5 days. 

Thanks for the comprehensive answer but still my problem is there. I try to
explain it more.  In my model I use AIM2 and in line 1769 the CVVN is
supposed to  have an amount but it is zero. When I tried to debug what was
the problem I found that CVVN is commented out in esrumfs/mfsbld.F therefore
it is zero in the subsys.F. If I reintroduce CVVN and reintroduce the day
type in this part of the code (which was there before and now it is part of
another if so it has to be reintroduced or it will be zero) the results are
the same as when I use AfnToBldData. And I don't think you changed that one
because according to your commit log r6548 (if you meant that because r6485
is written by Ian not you) you introduced another module which is fine. 

About the line 1897, previously the if statement was "If (IAIRN.ge.1)then ."
it was including AIM2and OPR as well as AFN but now it is only looking at
the AFN and it doesn't modify the CVVFM which results in an unbalanced
Zone_coupled heat advection. If you look at the dal/CHREM_report_data.F in
my branch there is a post processing parameter called fZN_AP_ZnCpldVent
(Zone_coupled heat advection) which should be the same with opposite signs
for two coupled zones. In case of using new If statement in line 1897 these
two numbers are dramatically different which is not the same as what I had
with previous version of development_branch. When I reverse it to previous
form (i.e. "If (IAIRN.ge.1)then ."  ) it works as expected both has the same
advection with opposite signs which makes sense. 

I hope I could explain what I meant.  I can send you three different results
by changing those parameters to show what I mean if you need that please let
me know and I can send you those.

Thanks, 

Sara

From: Ferguson, Alex [mailto:Alex.Ferguson at NRCan-RNCan.gc.ca] 
Sent: April 28, 2011 5:43 PM
To: s.nikoofard at Dal.Ca; esp-r at lists.strath.ac.uk
Subject: RE: Some bugs in subsys.F ?

Greetings from windy Ottawa!

I'm the author of recent changes [r6485] to subsys.F that alter use of the
PREC5N variables. In this revision, I modified MZVNT to allow more
flexibility in specifying infiltration air flow. These changes permit
switching from one air flow computation method to another (AIM-2, scheduled
flow and air-flow network) mid-simulation depending on the operating
conditions in the building. 

Prior to r6485, ESP-r held air infiltration and ventilation flow conductance
in the CVIN and CVVN arrays, in common PREC5N.  By default, ESP-r assumes
that the air flow rates are specified by hourly schedules in the .opr file.
CVIN and CVVN thus contain up to 72 separate flow rates for each zone: one
for each hour (1-24) in each of the three day types
(weekday/Saturday/Sunday). The routine MZVENC establishes values CVIN and
CVVN prior to commencing simulation using the static air change rates
specified in the .opr file.  During the simulation, ESP-r reads the
infiltration and ventilation data for the current hour and day type from
these arrays.

Rather than create a specific data structure, the air flow network exploited
the same variables for imposing network-computed infiltration and
ventilation flows on the building thermal model. There two deficiencies with
this approach:

*	It's cumbersome. Because CVIN and CVVN are designed to hold hourly
schedules, the air-flow network had to locate the correct array location
(that is, the current day type and hour) to save the data in, even though
these parameters had no relevance to the air-flow network computation. This
not only requires extra code; it also obfuscates the purpose of the
CVIN/CVVN arrays.
*	It erases the original schedules held in CVIN and CVVN.  These
arrays are populated prior to simulation by routine MZVENC. By repurposing
them, the air flow network overwrites the original flow schedules with
time-step computed values. This prevents re-imposing the .opr schedules
mid-simulation-a key objective in our work. 

For these reasons, I elected to revise routines MZVENT and MFLW2B to use
dedicated variables when imposing infiltration and ventilation on the
building thermal domain.  I introduced a new common block AfnToBldData
common for this purpose. 

Regarding your observations Sara, I'm not sure I understand your comments.
When the opr schedule or AIM-2 models are in effect, ventilation is still
governed by the hourly ventilation schedule-and therefore should be
established via CVVN as per line 1769. I'm also unsure what you're
suggesting regarding line 1897. The if statement has two clauses: bAFN =
TRUE for air flow networks, and an else clause otherwise. Am I missing
something?

Thanks,

- Alex 

Alex Ferguson
Housing, Buildings and Communities Group
CanmetENERGY
Natural Resources Canada
P:+1 613 995 3294
F:+1 613 996 9909
Alex.Ferguson at NRCan-RNCan.gc.ca

  _____  

From: Joe Clarke [mailto:joe at esru.strath.ac.uk] 
Sent: April 28, 2011 12:02
To: core_developers at espr.list.cvsdude.com
Subject: Re: AW: Some bugs in subsys.F ?

Dear All

In relation to Sara's recent post below, I have made changes to ESP-r to
enable the coupling of non-air flow networks to building models to allow the
use of ESP-r's building-side features in plant modelling. I use the
variables in common PREC5N extensively. The changes are at present resident
in my branch and not yet integrated in development_branch.

Regards,

Joe

I want to only give a heads up in a mistake occurred in development_branch
which should be fixed. It reflected in commit log 6618. Since the fluid flow
network solver no longer changes the PREC5N variables and data is stored in
the dedicated AfnToBldData common variables, the calculation of CV1, CV2 and
other related parameters there for AIM2 in subsys.F should be changed (line
1769 in development_branch). Using the current version cannot calculate CVVF
in the mode of AIM2 or OPR, so they have to be changed (which you can see in
commit log 6618). 

Another issue is in CVVFM modification line 1902. The if statement which is
in line 1897 is wrong, it doesn't account for other type of air flow network
which should consider them. It is also reflected in commit log 6618.

Best Regards,

Sara Nikoofard
Room C254A, Department of Mechanical Engineering, 
Dalhousie University, Halifax, NS
Phone: (902)494-3165
email: s.nikoofard at dal.ca

-- 
Professor J A Clarke                email: joe at esru.strath.ac.uk
ESRU, Dept. of Mechanical Eng.           phone: +44 141 548 3986
University of Strathclyde                  fax: +44 141 552 5105
Glasgow G1 1XJ, UK                 http://www.esru.strath.ac.uk/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.strath.ac.uk/archives/esp-r/attachments/20110505/1cc19664/attachment.html 