Calculated values in Schedules can't catch "null" yes/no parameters?

Calculated values in Schedules can't catch "null" yes/no parameters?

DilloinPDX
Contributor Contributor
2,350 Views
16 Replies
Message 1 of 17

Calculated values in Schedules can't catch "null" yes/no parameters?

DilloinPDX
Contributor
Contributor

Since we got the ability to use calculated values in labels I developed a system for calculating occupancy loads.  To that end, I wanted to create a schedule that users could look at to verify what they're seeing in the plans without switching back and forth.  Here's the formula in our tag:

 

if(not(ManualOccLoad), roundup(Area / OccFactor / 1 SF), OccupantLoad)

 

Where:

ManualOccLoad is a shared, project parameter (this is for rooms) of the Yes/No type (why I won't say Boolean in a moment)

OccFactor is a shared, project parameter of the integer type 

OccupantLoad is a shared, project parameter of the integer type

Area is the default Area parameter. 

 

The idea is if the manual checkbox isn't checked, just calculate the value from Occupancy Load and square footage.  If it is, use the manual entry as is.  

 

But that same formula does NOT work in a calculated value in a schedule.  For all project parameters of the "yes/no" type they are set to a "blank" state.  The formula in a label is fine with that.  In a schedule it doesn't capture the "blank" state. 

DilloinPDX_0-1658950222121.png

 

Any ideas on how to work around this?  Is it something that has been fixed since 2019? Is there a reason why we can't filter for that "blank" state or use a conditional?  

0 Likes
2,351 Views
16 Replies
Replies (16)
Message 2 of 17

ToanDN
Consultant
Consultant

Sort by the Y/N parameter, uncheck Itemize... then tick or untick the box in one go.

By the way, you can drive a lot of Occupancy parameters by a Key Schedule that may just render the NULL issue moot.

0 Likes
Message 3 of 17

barthbradley
Consultant
Consultant

Gray condition means that the Yes/No isn't activated.   To activate it, you need to manually set it.  

0 Likes
Message 4 of 17

DilloinPDX
Contributor
Contributor

Yes, you can do that... but it shouldn't be necessary.  And users tend to be hesitant utilize that workflow regardless how many times I show how useful it is.   The tag works perfectly fine with the exact same formula and without "setting" that value. I suspect the same problem would show up if I tried a conditional like: if(OccupantLoad>0, OccupantLoad, <calculate value>) 

 

Key Schedules (in 2019) can't utilize shared parameters. Project Parameters (not shared) can't be used in Tags. And regardless, if one instance of an occupancy type is using a calculated value, and another is using a manual override, a key schedule wouldn't circumvent the calculation problem.  

0 Likes
Message 5 of 17

DilloinPDX
Contributor
Contributor

Why does it work in a label and not a schedule? That's the question.  I completely understand how the parameter works.  

0 Likes
Message 6 of 17

barthbradley
Consultant
Consultant

@DilloinPDX wrote:

Why does it work in a label and not a schedule? That's the question.  I completely understand how the parameter works.  


 

 

It doesn't.  

 

Can you tell me how to replicate whatever it is that you are doing to make it so?  

0 Likes
Message 7 of 17

DilloinPDX
Contributor
Contributor

I'm using the exact same formula in a label inside a tag as I'm using in the schedule.  In the tag it works.  In the schedule it is not. Very simple. 

0 Likes
Message 8 of 17

DilloinPDX
Contributor
Contributor

Here it is in the label with the formula.  And a screen shot in use providing the needed values.  If I check the manual override (set the value to YES) the manual value is used.  I've had it in use for over a year.  Note the room selected has neither yes or no set for the override.  

 

DilloinPDX_0-1658952734270.png

 

0 Likes
Message 9 of 17

barthbradley
Consultant
Consultant

@DilloinPDX wrote:

I'm using the exact same formula in a label inside a tag as I'm using in the schedule.  In the tag it works.  In the schedule it is not. Very simple. 


 

Doesn't make sense to me.  What version of Revit?   

0 Likes
Message 10 of 17

ToanDN
Consultant
Consultant

.

 
0 Likes
Message 11 of 17

barthbradley
Consultant
Consultant

what does the tag report is the conditional statement omits the "not" (e.g. "if (Yes-No,.."  instead of "if (not(Yes-No),..."?   I imagine it reports correctly, if you have been using it.  

0 Likes
Message 12 of 17

DilloinPDX
Contributor
Contributor

This is revit 2019.  

 

There are 3 shared parameters. 

Occupant Load - number

Occupant Factor - number

Manual Occupant Load - yes/no

 

Since these are rooms, these are all project parameters.  

 

Create a room tag.  Create a label with a calculated value of a number. 

Here's the formula to use.  

if(not(Manual Occupant Load), roundup(Area / Occupant Factor / 1 SF), Occupant Load)

 

Add these same shared parameters to your project and apply to Rooms category. 

Place a NEW room.  Change Occupant Factor to whatever.  

Tag using the tag created above. 

Occupancy value will be displayed correctly as Area/Occupant Factor (rounded naturally).    

Put something in "Occupant Load" in the properties of room.  Nothing should change

Check "Manual Occupant Load".  Value in tag will update with value from Manual Occupant Load.

Uncheck "Manual Occupant Load." Value reverts to calculated value from Area/Occ Factor 

 

 

0 Likes
Message 13 of 17

barthbradley
Consultant
Consultant

I don't need to test. You both have provided empirical evidence.  I agree it's strange.  For that reason, I don't trust it 100%, so it won't be changing my workflow (e.g. activating the YES-NOs I create).    

0 Likes
Message 14 of 17

DilloinPDX
Contributor
Contributor

@barthbradley wrote:

what does the tag report is the conditional statement omits the "not" (e.g. "if (Yes-No,.."  instead of "if (not(Yes-No),..."?   I imagine it reports correctly, if you have been using it.  


For the tag, I kinda don't care.  It works. 

 

For the schedule I've tried multiple versions.  None will capture the condition when Yes/No is neither Yes or No.  

I've tried using 
if(and(not(YesNo), (YesNo)), calculate, override)

if(YesNo, override, calculate)

if(YesNo, override, if(not(YesNo), calculate, override))

None of these do anything different.  

On the database side, if you use snoop, it isn't a true "null" as someone once told me.  It is just "blank" or "un set". 

0 Likes
Message 15 of 17

DilloinPDX
Contributor
Contributor
I get it, not asking you to change anything.

My point being that it SHOULD work. This kind of formula works pretty reliably in a number of conditions. My point (ignore occupancy loads) is that the formula behaves differently and, in my mind, is broken in calculated values.
0 Likes
Message 16 of 17

ToanDN
Consultant
Consultant

@DilloinPDX wrote:

@barthbradley wrote:

what does the tag report is the conditional statement omits the "not" (e.g. "if (Yes-No,.."  instead of "if (not(Yes-No),..."?   I imagine it reports correctly, if you have been using it.  


For the tag, I kinda don't care.  It works. 

 

For the schedule I've tried multiple versions.  None will capture the condition when Yes/No is neither Yes or No.  

I've tried using 
if(and(not(YesNo), (YesNo)), calculate, override)

if(YesNo, override, calculate)

if(YesNo, override, if(not(YesNo), calculate, override))

None of these do anything different.  

On the database side, if you use snoop, it isn't a true "null" as someone once told me.  It is just "blank" or "un set". 


Schedules have existed since the dawn of Revit so their calculated parameters algorithm are based on the old database structure and rules.

Calculated value labels in tags were just introduced a few years ago so they are based on the new and improved database structure and rules.

 

Source: trust me dude.

0 Likes
Message 17 of 17

barthbradley
Consultant
Consultant

I understand your point.  I just don't share your assessment.  YES-NOs have two values in my mind's eye - not three.   My expectation is that NULL would drive nothing.  The fact that it does, is perplexing to me.  But even a broken clock is right twice a day.   

0 Likes