PROPERTIES (new): How do you get subtractions based on the current addition

[Aurasphere]

Lets say you are doing blockwork and creating the MCU list for estimating

Walls are generally using a property eg "MCU400.200" as the standard block

On openings in walls, obviously there are half blocks 

The walls are correctly reporting MCU400.200 and now a property assigned to the opening height caculates the half blocks and outputs MCU200.200 (the half block code)

BUT

normally this also becomes a subtraction because these blocks are replacing the full units and so there is the addition/subtraction going on. I dont want to model volume etc and of course there are instances where you mght override the expression in the opening and add a manual amount.

So how can you use the MCU200.200 property to create a negative MCU400.200?

I must be naive as it just doesnt seem to have a linked scope to be able to do it.

Operating system used: Windows

[Barry Kelly]

So in your wall, you have a property that correctly gives you the volume, area or number of half blocks under windows in that wall?

If so then you need another property with expression that deducts that volume or area of the half blocks from the overall wall volume/area (less openings) and then calculates the number of full blocks based on that reduced volume.

Or in the property that calculates the number of full blocks, deduct half the number of half blocks from the total number of full blocks.

Barry.

[Aurasphere]

Hi Barry

So in your wall, you have a property that correctly gives you the volume, area or number of half blocks under windows in that wall?

ie...the jambs of openings calculate the number of half block per opening in the wall.

This a property only available for that classification and object type (obviously not for a wall)

The global property that holds the property of the actual blocks is not available to this property (MCU400.200) = (M)asonry(C)oncrete(U)nit.400l. 200w

I cannot deduct from this amount it seems? Which is crazy compared to standard estimating workflows.

Normal estimating dependencies dictate; In the hierarchy of quantity, the parent quantity ie full blocks are subject to modulation.and in this case, even in the legacy, you are always globally referencing this qty

The child quantity being the half blocks is subsequent and its usually a simple thing of writing back the volume reduction to the parent ie its all referential

It must be interrogative because its conditional ie only an opening can contribute change.

So currently I cant see that properties are valid for this...or Im obviously missing something..If everything is singular and unrelated, it gets very complicated very quickly

Also, how is this summed and order in schedules without many columns when they arent shared scope?

Cheers 🙂

[Barry Kelly]

The walls are correctly reporting MCU400.200 and now a property assigned to the opening height calculates the half blocks and outputs MCU200.200 (the half block code)

Sorry, I just assumed that you were getting the property for opening heights from the wall.

But looking at the wall properties, I see you can't actually do that.

All you can get is the opening areas which does not help - you need just the sill area.

So from the wall you can get number of MCU400.400 blocks (based on the net wall area or volume).

From the window you can get the number of MCU200.200 blocks if they are needed (based on the window height).

Unfortunately the wall can not interrogate the properties associated to the windows (as far as I know).

You could schedule the block property (either area, volume or actual number of blocks) from the wall and the bock property (either area, volume or actual number of blocks) from the window  - possibly in the same schedule (I can't say I have tried) but definitely in separate schedules.

But even if they are in the same schedule, they would be different fields and therefore can not be summed, subtracted or totalled.

All I can think of is to include a half block sill for those windows that require it.

If the sill is modelled as part of the window, the overall area of the opening and sill will be deducted from the wall, so you can get accurate quants of the MCU400.400 blocks and create a schedule for that.

Then you can get schedule accurate quants of the MCU200.200 blocks from the windows.

So 2 separate schedules, but that should be OK as they are 2 separate materials.

Example of the sill area being deducted ...

Barry.

[Aurasphere]

Thanks Barry

The prob is is not a sill...which would be easy as most windows etc have that, its the jamb blocks ie the vertical so its not part of any normal stuff. I had a whole library of estimating parts when I did dedicated estimating but it needs to work out of the box

Ive honestly been doing it a long time ie blockwork estimating as part of my plans as I use a sustainable thermal performance block.. I wish I had of kept all the resources...even wall ends get used for open end walls.

It was all so easy with the legacy listing...and so industry standard...it just wasnt actually finished but def by peeps that knew how larger offices worked vs small architectural officies.

We would just get exported IFC, reapply the dedicated windows/doors/wallend and composites and create extremely accurate quotes with often just a handful of blocks left over of being short and then finding out theft occurred because we would count back the blockwork.

The truth is that new properties are a LONG way of replacing in any way, the legacy system but they do have some great features that could augment.

Additions and deductions are foundational and shouldnt be this hard

this text file was automatically written out to the required job in the office estimating system

You can see it references basic recipe of adding 13 half blocks (CS100 HLF) and  subtracting CS100 STD (Standard)

The PERFECT solution would be to amalgamate the old and new, drag and drop components from the legacy database onto elements either as single elements using expressions or current 'properties' as value pipes OR use recipes...then along with a wysiwig layout editor would be a mature and efficient package.

[Barry Kelly]

---

@Aurasphere wrote:

The prob is is not a sill...which would be easy as most windows etc have that, its the jamb blocks ie the vertical so its not part of any normal stuff. I had a whole library of estimating parts when I did dedicated estimating but it needs to work out of the box

---

Of course.

I am just thinking bricks were they just cut the brick in half on site.

Didn't even think about the sides of the windows.

I don't have any ideas to automate that.

Barry.

[Aurasphere]

Thanks for your always enthusiastic help Barry!