spqr's profile - activity

I just ran into this same issue. One work around is to use BEopt 2.7, this bug doesn't seem to be present in the older v

Did you ever find a solution to this question? I am attempting to control the stage of a heat pump (or at least the coil

I'm not currently using the Plugin in API mode, but maybe this would be a reason to re-structure my workflow. At least n

Communicate end of RunPeriod to Python Plugin Is there a mechanism in the Python Plugin API to communicate the impending

A complete working package that is easy for others to use would be great. However, even releasing some of the unpolished

Thanks for looking into this. I was able to see the same behavior using one of the PyEMS examples. I am also using the a

After some more investigation, it appears the density for a node is 0.0 during simulation warmup, but is then correctly

@rraustad Is the standard density reported as an Output:Variable? This would be handy when developing a Python Plugin th

I've worked through the different Python Plugin example files, and as far as I can tell, there isn't a way to do what I

EnergyPlus Python Plugin String Data Exchange When using the EnerygPlus Python API in plugin mode, I need to transfer ID

I was able to get the AFN working in our simulations. I had a bad value for the 'min density for two way flow' in the simple openings. So far the approach of using the adjacent zone as the return path seems to be working.

It turns out the issue was associated with our simple openings and the assumed value for "density difference for two way flow". Somehow a value of "1" had gotten into the file for each of our doorways, when a better value is 0.0001. I have tested the file now through a number of iterations and it seems to be working fine.

We are having success in using a 'leak' as the return path connecting the zone to an adjacent zone.

@BBel Were you ever able to model the return path as a simple opening? E+ Does not seem to like having a AFN:Multizone:Component selected where it should be a AFN:Distribution:Component. Have you had any success defining a supply terminal without the return pathway?

I currently have a house model with a detailed AFN. Each return from the zone is modeled as crack flow into the next space, however I am getting a matrix singularity error. Ideally I would not define a return object, as this does not exist in reality, the actual system has one point of return in a hallway.

@Lixing Gu I am still getting the error under various circumstances. I am creating and reviewing the *.dbg file and none of the HumRat values are at or near zero for the timestamp before the error.

• What values are stored in the MA array that would be zero? What would cause the node to network correctly for a while (say a month), and then suddenly stop working?

One potential source for solar data is the NSRDB. You can find this data via maps.nrel.gov and by selecting the NSRDB Viewer. However it appears they only have data through 2014, and not up to minute data.

You can download hourly GHI data as well as several other weather values.

I believe the solar data is generated by running cloud cover satellite imagery through a model.

I have updated the model to include a complete airflow network, however continue to get the error message. Sometimes a simulation will run for an entire year with no problem, sometimes it will run for a day or a month before kicking back with the error. I am modifying various HVAC system parameters such as fan flow rate, supply temp set point, total system capacity, duct length, duct U value, etc. The error is coming from a different thermal zone each time, but always seems to come from the zone outlet.

What values are feeding into the MA array? Is the model calculating 0 RH for a node?

Thank you both for the input. The problem does seem to be sensitive to the total fan / system airflow rate. If I set this low to perfectly match the sum of terminal flows, I get the error almost immediately. If I set the total fan flow to be higher (say double the sum of terminals), I can get the simulation to run almost a full year before it gives me the error.

I am following your advice and fully defining the airflow network and ductwork at the moment. I will check back in if that fixes the issue.

We are running a detailed EnergyPlus simulation of a house. The purpose is to have a detailed duct and airflow model for assessing the performance of HVAC air delivery components. We are currently in the process of defining and hooking up all of the zone nodes and ductwork, however I keep getting the following fatal error after the simulation has run for ~1 month: "A diagonal entity is zero in AirflowNetwork matrix ZONE3OUTLETNODE." ZONE3OUTLETNODE is currently defined as a leakage path from one of the bedrooms to the adjacent hallway, acting as the return air path.

Digging into the source, it appears the error is based off an integer comparison which should not be changing during simulation. I'm not that familiar with C++ or the E+ code so I may be mis-understanding what is occurring. I'm also not sure what the MA() command does.

// Check singularity
for ( i = 1; i <= AirflowNetworkNumOfNodes; ++i ) {
            if ( MA( ( i - 1 ) * AirflowNetworkNumOfNodes + i ) < 1.0e-6 ) {
                ShowFatalError( "CalcAirflowNetworkMoisBalance: A diagonal entity is zero ...

The relative humidity in both zones is something normal (10%-50%).

So far we have connected 6 of the 30 thermal zones into the AFN. I am hoping to troubleshoot errors and gain a better understanding of the simulation in this more simplified state before setting up the entire model in the AFN.

Has anyone encountered this error before? Are there known causes and fixes?

Other background: Initial model is created using Rhino and Honeybee. 1 minute simulation timestep Thermostat is being modeled by using an EMS to over-ride the fan airflow. (since E+ can't model an actual thermostat by default) Heating is from an electric coil, and cooling is from a simple DX coil.