C3D 2012 QTO report duplicates, payItem links, and volumes

[granite07]

There are three issues with the QTO function that I am unable to find an answer to:

1. The volume calculation for CY has a mystery internal constant or multiplier; what is the internal function?
2. The quantity report can have duplicate entries for the same link; how are these removed?
3. Some subassemblies start with Pave other Pave 1 and in the Code style edit pane sometimes one or the other is available; which do i use and what is 'Pave' with out a #?

These issues are documented here in more detail http://cife.stanford.edu/wiki/doku.php?id=granite:3dmodelling:qto#c3d_qto

Your help is appreciated

[granite07]

There is three one issue with the QTO function that I am unable to find an answer, and two resolved issues which the solutions need independent validation:

1. The volume calculation for CY has a mystery internal constant or multiplier; the internal functions are a) the depth value is kept as an int value so there are no fractional parts, b) the depth value is then divided by 12, c) the area value is kept as square feet without modification, and last d) the product of depth and area is divided by 27 - can someone validate this?
2. The quantity report can have duplicate entries for the same link; these are removed by a) creating a new payItem file with new (unduplicated from previous) payItem codes, and b) some payItems can be removed by deleting the corridor codes 'code set style', removing the code set style from the toolspace/settings/general/multipurpose styles/code set styles and then create a new codeset style - with the same name. Can someone validate this?
3. Some subassemblies start with Pave others with Pave1 and in the Code style edit pane sometimes one or the other is available; which do I use and what is 'Pave' without the 1 suffix?

These issues and proposed workaround solutions are documented here in detail http://cife.stanford.edu/wiki/doku.php?id=granite:3dmodelling:qto#c3d_qto

[Sinc]

1)  There is no "mystery internal constant or multiplier".  You posted a sample drawing in your Wiki page that was set to "Meters", but it was virtually empty, with no Corridor or QTO setup, so it's impossible to say what might be going wrong.  But since you also said in your Wiki page that you were drawing with 1 msu = 1 inch (something that is invalid in C3D), I think you are creating this problem yourself, through a combination of improper settings and program usage.

2)  Yes, it does sound like your problem is in the QTO setup.  But from the info given, it's impossible to say what exactly the problem is.

3)  The "Pave", "Pave1", and "Pave2" codes are either Link or Shape Codes, as defined by the Subassemblies used in your Corridor.  They are definitely NOT the same thing.  Usage of these codes is a very basic part of building Corridors, and is something you should have learned prior to getting into QTO.

Correct me if I'm wrong, but I thought Wiki pages were a place for people with spare time and extensive knowledge about a subject to share their knowledge...?  You still don't know how to use this program, and are writing a lot of incorrect things.  Isn't it counter-productive to create extensive Wiki issues that basically do nothing but document your own confusion and lack of understanding?  I'm not trying to be harsh, but you're going down some bad paths, and my opinion is that it would be a very large waste of time for others to follow you down those paths.  I can't help but think that if you'd gotten some official training several months ago, you would now be using C3D very effectively, rather than spinning your wheels so much and wasting so much time on those confusing Wiki pages.

[granite07]

thank you for your opinions, wikis have multiple uses - the one you described is not the context I am using it in - if you'd like I can explain through a phone call; my Skype is forest.peterson

I will answer your questions:

Yes - I still don't know how to use this program and maybe never will

Yes - I probably am writing a lot of incorrect things, that is the point of it

No -  it is not counter-productive to create extensive Wiki issues that basically do nothing but document my own confusion and lack of understanding - that is part of the learning process

Yes - you are trying to be harsh,

Yes - I am going down some bad paths but that is part of learning and helpful to place the correct paths in context

Yes - it would be a very large waste of time for others to follow me down those paths - that is why they are documented and so you do not need to

Yes - if I had official training several months ago I would now be using C3D very effectively (except for the location-based part since it does not exist in C3D) - also, training is the incorrect term, I think you meant 'learned from someone knowledgeable in C3D', that would have been nice.

No - you would still think I was spinning my wheels and wasting time on confusing Wiki pages, though I would not be posting questions about C3D so you would never know I was wasting time on confusing wiki pages unless you also help with questions concerning scheduling, estimating, and 4D simulation applications.

[gauss2069]

Just the mere fact of your title " C3D 2012 QTO report duplicates, payItem links, and volumes" tells me you are using C3D 2012. I think you really have issues working with the program. Be honest and you shall conquer! This discussion group has shaped me a whole lot. There is a vast array of information here and links. Please read blogs as well. Good luck!

[granite07]

where did that come from, nobody is disputing what version of C3D I am using? Yes, I have all the C3D blogs subscribed to on Google reader, they are very helpful.

This thread is off topic now, so I will repost the original questions as three new threads.

[granite07]

The QTO function in C3D 2012 volume calculation for CY appears to have multipliers and assumptions written into the sourceCode; these are

1. the depth value is kept as an int so there are no fractional parts, rounding the Pave1 depth from .951' to 1'
2. the Pave1 depth value is then divided by 12, indicating that the depth is assumed in inch
3. the area value calculated from length and width is kept as square feet without modification, and last
4. the product of the depth and computed area is divided by 27 to convert an assumed CF to CY

I documented the test here http://cife.stanford.edu/wiki/doku.php?id=granite:3dmodelling:qto#c3d_qto

Disclaimer: I am using inch msu, I do not recommend this, I do not know what I am doing, it is a one-time test to help understand C3D functions. I used the subassembly.MedianFlushWithBarrier. If what I found above is correct it helps explain specifically one reason why inch msu is unusable.

Can someone validate if the above four results are correct?

[gauss2069]

"Yes - I still don't know how to use this program and maybe never will" But you are very elaborate and yet you cannot admit to wanting to learn. Sinc broke it down very well. I think you got time on your hands learn the program? Good luck!

[granite07]

does anyone know the answer to the topic question of QTO volume calculation?

I appreciate the tangential advice from Sinc, he is a great knowledge base and very intelligent  but I'd like to stick with one topic in this thread. we can open another to focus on people that do not know what they are doing and need to learn; I will gladly discuss all those philosophical points with you there.

[gauss2069]

Can you post a very light dwg illustrating this? Let us put some meat to the bone. Something we can see troubling you in QTO.

[granite07]

the volume calculated from length*width*depth is very different than what is reported in the QTO report, why?

[granite07]

I posted the documentation and screen shots showing the rounding of the subassembly layer depth attribute values here as part of a discussion on associating subassembly property attributes with their respective code set style codes; while answering that question this threads question was also demonstrated.

http://forums.autodesk.com/t5/AutoCAD-Civil-3D/2012-subassembly-code-name-inconsistency-or-code-set-...