nikhilgupta10
commented
7 years ago nikhilgupta10 imported these comments from Sourceforge: The user dchassin does not exist anymore. Therefore assigning this to afisher1. "dchassin":I've had the same problem and I think \make install\ is conflicting with the downloaded install. Somehow when gridlabd runs it doesn't use the correct libraries and the modules are old while the unit file is new. I still haven't figure which is to blame or how to fix it. There are several tickets already open on these issues (861 and 862).,
"dchassin":- Description has changed:
Diff:
--- old
+++ new
@@ -5,6 +5,8 @@
Terminal outputs :
Results with R4779 of trunk :
Edited build.h content : #define BUILDNUM 4779
+
+~~~~~
apratt-23207s:ieee-node4-houses apratt$ /Users/apratt/Documents/NREL/Software/GridLAB-D/GLD_3.0_R4779/bin/gridlabd --version
GridLAB-D 3.0.0-4779 (Hatwai) 64-bit MACOSX RELEASE
apratt-23207s:ieee-node4-houses apratt$ /Users/apratt/Documents/NREL/Software/GridLAB-D/GLD_3.0_R4779/bin/gridlabd IEEE_4_node_houses.glm
@@ -22,11 +24,13 @@
WARNING [2013-08-10 00:00:01 EDT] : transformer:transformer23 is at 101.03% of its rated power value
WARNING [2013-08-13 23:55:01 EDT] : last warning message was repeated 2565 times
apratt-23207s:ieee-node4-houses apratt$
-
+~~~~~
Results with R4707 of trunk :
Edited build.h content : #define BUILDNUM 4707
+
+~~~~~
apratt-23207s:ieee-node4-houses apratt$
apratt-23207s:ieee-node4-houses apratt$
apratt-23207s:ieee-node4-houses apratt$ /Users/apratt/Documents/NREL/Software/GridLAB-D/GLD_3.0_R4707/bin/gridlabd --version
@@ -38,3 +42,5 @@
WARNING [INIT] : NHTS data file not found, using defaults
WARNING [2013-08-10 00:00:01 EDT] : transformer:transformer23 is at 101.03% of its rated power value
WARNING [2013-08-13 23:55:01 EDT] : last warning message was repeated 2494 times
+
+~~~~~
,
"dchassin":I checked my Mac system this morning. The downloaded version is
GridLAB-D 3.0.0-4524 (Hassayampa) 64-bit MACOSX RELEASE
The output of house example is
david:~ david$ gridlabd --example residential:house
WARNING [INIT] : house_e:0 has no parent triplex_meter defined; using static voltages
object house:0 {
...
UA +0 Btu/degF;
...
}This is evidence of the erroneous unit parsing in that version. Periods are ignored instead raising an error resulting in a wrong unit spec for UA (it should be Btu/degF*h).
After I go to my working copy of trunk and do a \make install\, the version is
GridLAB-D 3.0.0-4775 (Hatwai) 64-bit MACOSX RELEASE
and the output of house example is
david:trunk david$ gridlabd --example
ERROR [INIT] : --example requires a module:class argument
FATAL [INIT] : shutdown after command line rejected
david:trunk david$ gridlabd --example residential:house
ERROR [INIT] : unit_find(char *unit='Btu.h/degF'): unitfile.txt(202): unable to find or derive unit 'Btu.h/degF'
ERROR [INIT] : could not find unit 'Btu.h/degF'
ERROR [INIT] : property_malloc(oclass='waterheater',...): property tank_UA unit 'Btu.h/degF' is not recognized
ERROR [INIT] : unit_find(char *unit='Btu.h/degF'): unitfile.txt(202): unable to find or derive unit 'Btu.h/degF'
ERROR [INIT] : could not find unit 'Btu.h/degF'
ERROR [INIT] : property_malloc(oclass='refrigerator',...): property UA unit 'Btu.h/degF' is not recognized
WARNING [INIT] : house_e:0 has no parent triplex_meter defined; using static voltages
object house:0 {
...
UA +0 Btu/degF*h;
...
}House looks correct to me but waterheater and refrigerator are wrong. I know I fixed these in the original ticket. I don't know how the merge got messed up, but we've been having lots of problems with that process lately. Since house is fixed already I'm going to break all the rules and fix them directly in the trunk this morning. ,
"dchassin":Done. Validation report:
459 models tested 459 tests succeeded 100% success rate
I hope Jason doesn't get too upset about me fixing trunk directly (that's a big no-no). But I think merge was the cause of the problem so doing another merge might not be the best solution now. I think there's a project team conference call later this week to discuss ticket merge issues but the problems seems to be growing out of control and we don't know why.,
"dchassin":FYI, here my current output for the refrigerator example. It looks correct now. BTW, the waterheater example fails because the default values are not physically valid. (We need a new ticket for that issue.)
david:trunk david$ gridlabd --version --example residential:refrigerator
GridLAB-D 3.0.0-4781 (Hatwai) 64-bit MACOSX RELEASE
WARNING [INIT] : (null) (refrigerator:0) parent object lacks air temperature, using 72.000000 degF instead
object refrigerator:0 {
// header properties
rank 0;
clock (invalid);
flags (invalid);
// refrigerator properties
size +23.9374 cf;
rated_capacity +816.743 Btu/h;
temperature +38.1227 degF;
setpoint +38.3484 degF;
deadband +2.4032 degF;
cycle_time +0 s;
output +0;
event_temp +0;
UA +0.6 Btu/degF*h;
compressor_off_normal_energy +40500;
compressor_off_normal_power +15 W;
compressor_on_normal_energy +252000;
compressor_on_normal_power +120 W;
defrost_energy +1.32e+06;
defrost_power +550 W;
icemaking_energy +18000;
icemaking_power +300 W;
ice_making_probability +0.02;
FF_Door_Openings 0;
door_opening_energy 0;
door_opening_power 0;
DO_Thershold +1.18576e-322;
dr_mode_double +0;
energy_needed +0;
energy_used +0;
refrigerator_power +0;
icemaker_running FALSE;
check_DO 0;
is_240 FALSE;
defrostDelayed +0;
long_compressor_cycle_due FALSE;
long_compressor_cycle_time +0;
long_compressor_cycle_power +120;
long_compressor_cycle_energy +720000;
long_compressor_cycle_threshold +0.05;
defrost_criterion TIMED;
run_defrost FALSE;
door_opening_criterion +0;
compressor_defrost_time +0;
delay_defrost_time +28800;
daily_door_opening 0;
state 0;
}
~~~~~,
"dchassin":A closing (non-technical) remark. I owe you (and Nate) an apology for first ignoring and then misdiagnosing this problem when I noticed it on my system about a week ago. It didn't affect my work, so I conveniently blamed my multiple installs and alleged download/make install problems and ignored it in the vain hope that somebody else would fix the problem before it got noticed. I was wrong on all counts. As usual, it is a reminder that the purpose of my life is to serve as a warning to others. See http://www.despair.com/mistakes.html for the demotivational message where I first had this epiphany.,
"jcfuller":- **assigned_to**: David P. Chassin
- **Milestone**: Unscheduled --> Version 3.1 Stable
- **Priority**: none --> blocker
,
"jcfuller":So, status? This is fixed in trunk, but does it need to be migrated to v3.1 (or was it only a trunk problem)?,
"dchassin":I got an email from Annabelle saying it was ok, but I'd like to have her confirm that here for the record before we close it.,
"dchassin":- **status**: new --> accepted
,
"dchassin":This is fixed as of r4785.,
"prtcoder1":I only observed this behavior on the trunk, but I have not tried it on a recent version of 3.1, since I'm using a ticket of 3.1 (ticket 716, R4711). I only observed this since I was helping a colleague install the trunk version.
,
"dchassin":When you have a chance, please update from trunk and try again. Let us know if we have fixed the problem. You may have to delete the file core/build.h because it might have been corrupted.,
"dchassin":Fixed in 3.1 in r4787,
"dchassin":- **status**: accepted --> closed
- **Resolution**: none --> fixed
,
"bpalmintier":I am still encountering this problem with the latest version of trunk (r4794).
Specifically:
$ gridlabd-trunk --version
running gridlabd from outside installation exec_prefix
GridLAB-D 3.0.0-4790 (Hatwai) 64-bit MACOSX RELEASE
$ gridlabd-trunk IEEE_13_Node_Test_Feeder.glm
running gridlabd from outside installation exec_prefix
ERROR [INIT] : compound unit 'pu.s' could not be correctly identified
ERROR [INIT] : unit_find(char *unit='pu.s'): unitfile.txt(202): unable to find or derive unit 'pu.s'
ERROR [INIT] : could not find unit 'pu.s'
ERROR [INIT] : property_malloc(oclass='frequency_gen',...): property M unit 'pu.s' is not recognized
,
"bpalmintier":And with the latest version of 3.1 (r4797).
Specifically:
$ gridlabd-3.1 --version
running gridlabd from outside installation exec_prefix
GridLAB-D 3.1.0-4797 (Hatwai) 64-bit MACOSX RELEASE
$ cd ../bin/3.1/share/gridlabd/
$ gridlabd-3.1 IEEE_13_Node_Test_Feeder.glm
running gridlabd from outside installation exec_prefix
ERROR [INIT] : unit_find(char *unit='ohm.h/Btu'): unitfile.txt(202): unable to find or derive unit 'ohm.h/Btu'
ERROR [INIT] : could not find unit 'ohm.h/Btu'
ERROR [INIT] : property_malloc(oclass='pqload',...): property Zp_S unit 'ohm.h/Btu' is not recognized
ERROR [INIT] : unit_find(char *unit='ohm.h/in'): unitfile.txt(202): unable to find or derive unit 'ohm.h/in'
ERROR [INIT] : could not find unit 'ohm.h/in'
ERROR [INIT] : property_malloc(oclass='pqload',...): property Zp_R unit 'ohm.h/in' is not recognized
ERROR [INIT] : compound unit 'deg.h' could not be correctly identified
ERROR [INIT] : unit_find(char *unit='deg.h/Btu'): unitfile.txt(202): unable to find or derive unit 'deg.h/Btu'
ERROR [INIT] : could not find unit 'deg.h/Btu'
ERROR [INIT] : property_malloc(oclass='pqload',...): property Ia_S unit 'deg.h/Btu' is not recognized
ERROR [INIT] : compound unit 'deg.h' could not be correctly identified
ERROR [INIT] : unit_find(char *unit='deg.h/in'): unitfile.txt(202): unable to find or derive unit 'deg.h/in'
ERROR [INIT] : could not find unit 'deg.h/in'
ERROR [INIT] : property_malloc(oclass='pqload',...): property Ia_R unit 'deg.h/in' is not recognized
ERROR [INIT] : unit_find(char *unit='VAr.h/Btu'): unitfile.txt(202): unable to find or derive unit 'VAr.h/Btu'
ERROR [INIT] : could not find unit 'VAr.h/Btu'
ERROR [INIT] : property_malloc(oclass='pqload',...): property Pq_S unit 'VAr.h/Btu' is not recognized
ERROR [INIT] : unit_find(char *unit='VAr.h/in'): unitfile.txt(202): unable to find or derive unit 'VAr.h/in'
ERROR [INIT] : could not find unit 'VAr.h/in'
ERROR [INIT] : property_malloc(oclass='pqload',...): property Pq_R unit 'VAr.h/in' is not recognized
ERROR [INIT] : compound unit 'pu.s' could not be correctly identified
ERROR [INIT] : unit_find(char *unit='pu.s'): unitfile.txt(202): unable to find or derive unit 'pu.s'
ERROR [INIT] : could not find unit 'pu.s'
ERROR [INIT] : property_malloc(oclass='frequency_gen',...): property M unit 'pu.s' is not recognized
,
"dchassin":Andy said he was fixing this yesterday but I don't see a commit for either 3.1 or trunk yet.,
"jcfuller":Be patient. This appears to be fixed. But, PNNL staff had little to no internet access and a power failure yesterday. Laurentiu will be pushing out updates (at least 4 or 5 classes still needed to be updated) today.,
"bpalmintier":Thanks for the updates. Latest from my testing:
trunk (r4806) now seems to handle units right, but 3.1 (r4797) still does not.,
Hello - I tried to install the latest version of the trunk - R4779 last week on a Mac, and it generated errors related to units. I rolled back to version R4707 and didn't have any issues with that version.
The output didn't change for the --version command between the builds - both reported R4775, so I manually edited the build.h file per my notes below.
Terminal outputs : Results with R4779 of trunk : Edited build.h content : #define BUILDNUM 4779
Results with R4707 of trunk : Edited build.h content : #define BUILDNUM 4707