TBC Macros and Extensions

 View Only
Expand all | Collapse all

computing volumes

  • 1.  computing volumes

    Posted 12-06-2021 00:06
    I've been digging into volume computations via a macro, initiated by this Thread https://community.trimble.com/communities/community-home/digestviewer/viewthread?GroupId=397&MessageKey=bf4b96e6-a3af-4ee0-aeb1-fcf668a04680&CommunityKey=d961b046-1661-40f3-8d7e-0bde6866a14d&tab=digestviewer

    My macro does successfully compute some values correct but the interval volumes don't match the earthworks report and also don't add up to the overall volume and should increase with the index as well.
    Any idea what could be wrong or how to interpret those values.

    The VS Object Browser states for that pinkish input above.
    Since I use DatumToDtm I should be able to use null/none. It does not accept None. But maybe it's just copy/paste from ComputeVolumeIsopach and is incorrect.

    (As a test I also created a Surface at elevation Zero and tried that instead of the original surface in that second ComputeVolumeResults. The overall volume still turns out correct, but all intervals turn to zero.)

    Ronny Schneider

  • 2.  RE: computing volumes

    Posted 12-29-2021 06:34
    Edited by Ronny Schneider 12-29-2021 09:42
      |   view attached
    Today I had some time to look into it again, and after some time I had the epiphany.

    Interesting is that this is only necessary if the summary is set to "ByElevation". If you set it to "ByDepth" you can enter the original surface at this point (the ComputeVolumeResults).

    But in the end you have to define the "None" Strongbox anyway for the "ComputeVolumeIsopach".

    So, I've put it together into a simple macro for the thread with the original idea.

    While on it I also explored contour creation.  And unit conversion since TBC computes internally in meters. The macro should now work with whatever is set in the project as volume and linear unit.
    Conversion to meter and back to display units. Was shown in some other macros, but not the abbreviation retrieval for the input labels.

    I also tested a recursive Algorithm with changing Datum and Volume Totals, but it is much slower. In every loop it treats the surface as unknown and needs to compute the prisms, holes etc. from scratch again.

    Ronny Schneider


    SCR_BasinFindVolumeRL.zip   6 KB 1 version

  • 3.  RE: computing volumes

    Posted 12-29-2021 20:46
    Edited by Ronny Schneider 12-29-2021 20:51
      |   view attached
    Since the recursive algorithm was so slow and with the slicer approach I have a list with volumes I thought why not create contours at volume intervals. Might be useful for flood simulations.
    I renamed the whole macro to "VolumeContours".
    The TBC-built-in function to compute all this starts to return only total volumes if I go below a certain slice thickness, 0.0001 m / 0.000329 ft. Which is surprisingly smaller than the earthworks report can do, which starts to return totals if I go below 0.001 m.

    Keep in mind that even with 0.0001 m slices the volume on large surfaces changes too much to compute a 100% accurate result. The result/contour is created once the slice sum is >= the target or the interval.

    The earthworks report into Excel also seems to be super inefficient. On a tiny test surface with 10 triangles, 10 m height and slice thickness 0.001 m I can't even press the stop watch quickly enough with my macro, but the report into Excel takes 6 minutes for those 10000 lines. HTML report is much quicker, about 3 seconds, but wouldn't give you all the slice volume decimals.

    Ronny Schneider


    SCR_VolumeContours.zip   7 KB 1 version

  • 4.  RE: computing volumes

    Posted 02-17-2022 14:54
    Nice one Ronny. I recon with will be good for the farm dam designs we do from time to time.


    Rob Davidson