Is this bug in Ladybug or OpenStudio API?

I used exportOpenStudio component to run idf file.
However, I got error because of the ComponentCost:LineItem/Line Item Type spell is wrong (It should be Construction, but it write Constuction) as below.
Does anyone know where I can fix this problem?

@KatsuyaObara ,
I am 99% sure that it’s not a Honeybee issue as none of the components that I know of deal with the ComponentCost objects. Where did the OpenStudio model come from? Is it possible that it’s not a bug at all but just something that was input incorrectly in OpenStudio?

I should also as, are you applying any Measures to this OpenStudio model?

As shown below, create basic geometry in Rhino and convert into idf format going through Honeybee component. (I didnt go through any OpenStudio interface to input data)
I guess this is the bug for OpenStudio API v2.5 then. Are there any way not to write ComponentCost objects through Honeybee interface? Since cost is not the main topic in this study, I dont mind not to calculate cost.

I am applying Set_Output_Table_to_IP_units measure through honeybee component

@KatsuyaObara ,

The issue definitely seems related to your measure and not to Honeybee.
Have you tried doing a Cntrl+F through the ruby file of the measure for the misspelled word?


1 Like

The measure fails because of line 80 in this BCL measure “SetOutputTableToIPUnits” where “construction” is misspelled.

	string_objects <<"
	#{used_construction_name}_TakeOff,	!-Name
	,									!-Type
	Constuction,						!-Line Item Type
	#{used_construction_name},			!-Item Name
	,									!-Object End Use Key
	,									!-Cost per Each {$}
	.0000000001;						!-Cost per Area {$/m2}

It’s not relevant to the measure and seems like it was left in from hastily copied measure code.

Lesson - be careful about downloading measures on BCL if they don’t have unit tests. Measures under the NREL and UnmetHours organizations are on GitHub and have testing/uploading procedures, so those are more likely to work consistently.

I have access to the organization that posted it, so I’ll update the measure and repost to BCL.


Thank for the detective work @mdahlhausen ! Gald that fixed it.

I see now why you were cautious to add all of your measures without unit tests to the BCL. They are clearly very important for cases like this :slight_smile:


Tests are important! My tests are often longer and more time consuming than the actual measure code. But time spent on tests will save users much more time.

@KatsuyaObara I’ve updated the measure on BCL. Re-download it and your workflow should be good to go.

1 Like