michael-bbs
commented
5 years ago created a pull request with much possible fixes, but @jonoxia there are some errors that are getting triggered by your unit validation code, @joelebwf how you think we should address those?
Case 961 should have succeeded, raised No unit given for concept solar:EstimationPeriodForCurtailment, requires type xbrli:durationItemType Case 974 should have succeeded, raised No unit given for concept solar:EstimationPeriodForCurtailment, requires type xbrli:durationItemType Case 987 should have succeeded, raised No unit given for concept solar:EstimationPeriodForCurtailment, requires type xbrli:durationItemType Case 1000 should have succeeded, raised No unit given for concept solar:EstimationPeriodForCurtailment, requires type xbrli:durationItemType Case 1013 should have succeeded, raised No unit given for concept solar:EstimationPeriodForCurtailment, requires type xbrli:durationItemType Case 1026 should have succeeded, raised No unit given for concept solar:EstimationPeriodForCurtailment, requires type xbrli:durationItemType Case 1039 should have succeeded, raised No unit given for concept solar:EstimationPeriodForCurtailment, requires type xbrli:durationItemType Case 1268 should have succeeded, raised No unit given for concept us-gaap:PrepaidExpenseCurrentAndNoncurrent, requires type xbrli:monetaryItemType Case 1536 should have succeeded, raised No unit given for concept dei:LegalEntityIdentifier, requires type dei:legalEntityIdentifierItemType Case 1560 should have succeeded, raised No unit given for concept solar:ModuleShortCircuitCurrent, requires type num-us:electricCurrentItemType Case 1586 should have succeeded, raised No unit given for concept solar:InverterOutputRatedFrequency, requires type num-us:frequencyItemType Case 1612 should have succeeded, raised No unit given for concept solar:ExpectedInsolationAtP50, requires type num-us:insolationItemType Case 1645 should have succeeded, raised No unit given for concept solar:SystemMinimumIrradianceThreshold, requires type num-us:irradianceItemType Case 1669 should have succeeded, raised No unit given for concept solar:TrackerAzimuth, requires type num-us:planeAngleItemType Case 1705 should have succeeded, raised No unit given for concept solar:SiteBarometricPressure, requires type num-us:pressureItemType Case 1729 should have succeeded, raised No unit given for concept solar:TrackerStowWindSpeed, requires type num-us:speedItemType Case 1755 should have succeeded, raised No unit given for concept solar:ModelAmbientTemperature, requires type num-us:temperatureItemType Case 1779 should have succeeded, raised No unit given for concept solar:InverterInputMaximumVoltageDC, requires type num-us:voltageItemType Case 1805 should have succeeded, raised No unit given for concept solar:SiteAcreage, requires type num:areaItemType Case 1829 should have succeeded, raised No unit given for concept solar:ExpectedEnergyAtP50, requires type num:energyItemType Case 1855 should have succeeded, raised No unit given for concept solar:ModuleLength, requires type num:lengthItemType Case 1881 should have succeeded, raised No unit given for concept solar:InverterWeight, requires type num:massItemType Case 1907 should have succeeded, raised No unit given for concept solar:BatteryInverterACPowerRating, requires type num:powerItemType Case 1929 should have succeeded, raised No unit given for concept solar:WashingAndWasteQuantityOfWater, requires type num:volumeItemType
Currently 188 out of 304 test cases fail. This could either be issues in pyoblib or it could be that the test cases themselves are not accurate reflections of anticipated results. Either way they should be resolved such that the number is 0 failures. Once this is done the test case logic should be updated such that Travis fails when test_json_clips fails (currently it just prints the results). Please note that this issue does not stop pyoblib from being used, rather it just reflects that validation is not as tight as expected.