Areas within Contours

[schneidrax]

Some time ago Matt Peter was looking for a way to determine the area within successive contours [Collaboratory, Earth Sciences, Estimation of Mass Flux (6 Dec 2002)]. More recently, I've had the same requirement.

Although my collaboratory search proved fruitless, I was able to develop several algorithms of my own. One set of algorithms can be used to find the area between successive contours; the other set can be used to "integrate" one three-dimension function within limits determined by the contours of a second three-dimensional function.

These algorithms may not be particularly robust, but they seemed adequate for my problem. Perhaps other collaborators can suggest improvements or alternatives.

[TomGutman]

It's a farily rough approximation to the area, counting the number of grid points within the desired area.

No need to calculate an array only to sum its elements. You can just do the sum directly as you calculate.

The technique of localizing TOL is broken in MC14.
__________________
� � � � Tom Gutman

[schneidrax]

Tom:--Thank you for your suggestions. I've incorporated them into the version attached below.

Jean:--As originally posted, Contour_Areas_1.mcd required the ROUND function to execute Method III. Application of the ROUND function following CreateMesh seemed convoluted since ROUND doesn't accept an array as an argument. After introducing Tom's suggestions, ROUND was no longer required and CreateMesh was incorporated into the program - now much improved.

Thank you both.

All:--Any suggestions for improving Contour_Areas_2.mcd?

[schneidrax]

On 7/22/2009 8:59:47 AM, schneidrax wrote:
>
>All:--Any suggestions for
>improving Contour_Areas_2.mcd?

I should have attached my own (see below).

[schneidrax]

On 7/22/2009 9:51:46 AM, jmG wrote:
>
>What I don't understand
>immediately is the green
>numbers varying so much with
>various meshing. Those numbers
>seem to be the number of
>square mesh falling within the
>contours. There may be a
>supplementary scaling factor
>to apply for a "metric unit
>area" ... ft�, m�.
You're absolutely correct, Jean.

>The other
>point is that this is the area
>between projected contours, it
>is not the surface area
>between contours on the solid.
I presume that you're considering the contours of z=f(x,y) a surface. But because this surface in cartesian space is not being re-maped by some coordinate transformation, projected areas shouldn't be an issue here.

[TomGutman]

>>projected areas shouldn't be an issue here.<<

Projected area is what you are approximating. I assume that is what you are intending to calculate, and is the appropriate area measurement for your application.
__________________
� � � � Tom Gutman

[schneidrax]

On 7/23/2009 4:31:35 AM, Tom_Gutman wrote:
>>>projected areas shouldn't be an issue here.<<
>
>Projected area is what you are
>approximating. I assume that
>is what you are intending to
>calculate, and is the
>appropriate area measurement
>for your application.
>
You are correct.
And thanks again for your help.

[schneidrax]

Jean:--

An interesting approach. But I was unable to show that your results are consistent with mine. Perhaps you could demonstrate this?

[ptc-1368288]

On 7/23/2009 10:06:17 AM, schneidrax wrote:
>Jean:--
>
>An interesting approach. But
>I was unable to show that your
>results are consistent with
>mine. Perhaps you could
>demonstrate this ?
_______________________________

Sorry for that, I removed all the attachments.
My concept is OK, but the construct is wrong.

Hopefully it might come out, sometimes.

Jean

[ptc-1368288]

On 7/23/2009 7:37:58 PM, jmG wrote:
>On 7/23/2009 10:06:17 AM, schneidrax
>wrote:
>>Jean:--
>>
>>An interesting approach. But
>>I was unable to show that your
>>results are consistent with
>>mine. Perhaps you could
>>demonstrate this ?
>_______________________________
>
>Sorry for that, I removed all the
>attachments.
>My concept is OK, but the construct is
>wrong.
>
>Hopefully it might come out, sometimes.
>
>Jean
________________________________

Here is, a gorgeous tool !
This is a typical project that if Mathcad 14 can't do... [no comment]. This is the "metric area" ..."�, m�, ft� ... etc. The c(x) is general but not looked for "specific". It might need some tweak. Your typical function works, but it does not show the complete "S shape" that is needed for basic demo.
Saved 2001i, thanks for the exercise.

Jean

[ptc-1368288]

... your project is now done for a single contour in "metric area". The previous version will surely fail for Mathcad 14 because of the MuPad, and it applies to mathematical function f(x,y). This is not general enough as the surface area may result from square/rectangular data sets, mostly smoothed, therefore, the sole contour extractor will be this one attached, though here for your particular project, it is applied on your function. Compacting the entire thing in a single program is always prone to failure, not knowing where and why it fails, thus the proposal is left in modular construct, much easier to debug. Rarely, programs can be "general-general-general...".

As is ... but not limited to refinements.

Jean

[ptc-1368288]

Final FD (Finite Differences).

jmG

[TomGutman]

Just had a thought. What you are doing is counting the number of values within ranges. That is commonly known as a histogram and Mathcad has some functions for calculating them.
__________________
� � � � Tom Gutman

[schneidrax]

On 7/24/2009 5:56:30 AM, Tom_Gutman wrote:
>Just had a thought. What you
>are doing is counting the
>number of values within
>ranges. That is commonly
>known as a histogram and
>Mathcad has some functions for
>calculating them.

Good idea. Works like a charm (file attached). Offers lots of options by choosing between HIST or HISTOGRAM, and uniform or non-uniform bins (contour intervals).

I don't think though that it can be easily generalized for the application addressed previously in the file Contour_Areas_2.mcd