Get Help

Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Community
- :
- PTC Mathcad
- :
- PTC Mathcad
- :
- Horrible Polar chart

Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

10-02-2010
06:51 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-02-2010
06:51 AM

Horrible Polar chart

I'm plotting a polar chart with 2 dependent variables

EA(dh) and AZ(dh) both are dependent on dh variable and both are angles.

A rectangular plot between them works fine but the polar chart is all screwy. See the attached image and mathcad file

22 REPLIES 22

10-02-2010
06:33 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-02-2010
06:33 PM

The file has a problem for me in M14 020 with the def of Longitude. The first time that I tried to fix it, Mathcad blew up. The next time, I edited it differently, and got the file to run.

I changed the def of dh to dh:=0,0.01..23.99

...gotta go...more later...

~R~

10-03-2010
08:03 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-03-2010
08:03 AM

Rich Messeder wrote:

The file has a problem for me in M14 020 with the def of Longitude. The first time that I tried to fix it, Mathcad blew up. The next time, I edited it differently, and got the file to run.

No problem for me!!!!!

M14 000.

Mike

10-02-2010
09:01 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-02-2010
09:01 PM

...so, the polar plot looked like it was plotting correctly. Recalling that the polar plot uses radians for its angle axis, I made the adjustment in the attached file. I also set the radial axis to display negative values, because otherwise the negative values make the plot look what it ain't. The polar plot now shows the sun rising @ azimuth xxdeg, rising quickly to nearly yydeg, plateauing or peaking there, etc...

~R~

10-03-2010
08:05 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-03-2010
08:05 AM

Nice work Rich,

This was bugging me yesterday.

Mike

10-03-2010
12:35 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-03-2010
12:35 PM

Thank you we are getting somewhere.

1) the hours dh is actually UTC time. I have to make adjustments when plotting to use local time.

2) for solar calculations we don't care about negative elevations. We only care about the morning. I'm attaching a solar polar chart for reference.

3) the center of the plot should be 90degrees and the outside 0 degrees.

lastly whats the best way to make Elevation and azimuth angle a function of date as well as function of time. So i can plot the sun path for specific dates.

BTW should i post this file after i'm done so other solar engineers can plot the charts as well. I'm sure someone else can benefit from this as well. Is there a repository for mathcad examples available.

10-03-2010
05:29 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-03-2010
05:29 PM

Hello Ziyad,

Please do post the final worksheet. This community is for users to share their work. I suggest you post it under Aerospace Engineering and add some tags to make it easier for other users to find it.

Best regards,

Mona

10-04-2010
09:58 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-04-2010
09:58 AM

>3) the center of the plot should be 90degrees and the outside 0 degrees.

Well, I don't think that is possible with Mathcad polar plots, though I haven't given it a run. If it works, all you need to do is swap the values for the radius range on the right side of the plot.

>lastly whats the best way to make Elevation and azimuth angle a function of date

You'd have to make a function that wraps up the variables that you want as options: something like PSA_SPC (date, time, lat, lon, etc)...the function would have to include calcs from the document that are now global, and have it return the EA & AZ vectors.

>BTW should i post this file after i'm done

Definitely. We often see folks posting files just in case aomeone else might find them useful. For example, there was a discussion a year or so ago about photography, but there is no photography forum. So post it where you think it will do the most good - one copy only, please! (Vasili) - in the forum of your choice. "Other subjects" might be a good choice, if you don't think it belongs elsewhere. I can think of several forums to post it in. The important thing is to have a good subject line and good text in the body of the message so that folks can find it if they do a search on relevant keywords.

~R~

10-03-2010
06:42 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-03-2010
06:42 PM

When plotting Elevation versus Azimuth graph for lets say 12 different dates. I'll have 12 different arguments for yaxis and 12 arguments for x axis.

Is there a way to put all those arguments in a vector and just plot that vector so i on;y have just one argument in y and x axis

10-04-2010
03:03 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-04-2010
03:03 AM

You could use the stack function ----stack(a,b,c,d)

Mike

10-04-2010
09:47 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-04-2010
09:47 AM

like this?

y(x):=stack(f(x),g(x),h(x))

10-04-2010
09:53 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-05-2010
10:33 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-05-2010
10:33 AM

Ziyad,

Did you sort your problem?

Mike

10-05-2010
01:37 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-05-2010
01:37 PM

there are certain conventions regarding solar polar charts

1) the inside of the radial axis should be 90deg and outside 0deg

2) the north side should be 0deg.

Due to limitations in mathcad polar charts i'm unable to get my chart the way it's supposed to be.

I have gotten the chart correct but hidden the wrong axis label. Thats the best i can get so far. will see if mathcad prime gives us more flexibility.

10-05-2010
04:07 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-05-2010
04:07 PM

It's true that the Mathcad polar plot won't let you swap the radial range. You could still swap the values with a calculation, plot them, and suppress (don't display) the numbers on the axis.

You could subtract pi/2 in AZ(dh) to rotate the the plot CW.

The usual sun polar plot has the angle going CW, not CCW, the Mathcad standard. Unfortunately, you can't swap those angles, either. I think that all this has been addressed with Mathad in the past. Puzzling that so little attention has been given to the polar plot. At any rate, you could also swap /angular/ values, plot them, and suppress the angular numbers.

You could make EA(dh) a NaN unless the result is .gte. zero.

You might consider making your functions return a value rather than a range. My understanding of Mathcad is that ML(dh) (for example) creates a range, and each time that ML(dh) is called, the the range is executed. A bit inefficient WRT calculation time, though perhaps not important at this level. Easy enough to test in a test loop, but maybe those w more experience will weigh in and clarify.

~R~

10-05-2010
04:30 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-05-2010
04:30 PM

I'm attaching my current file

So you can see what i have so far. It's getting longer and longer.

Right now If i give it a date it plots me Elevation and Azimuth angles. Plots me the Solar radiation through out the day. Plots me solar radiation on a solar panel at a particular angle through out the day so you can see how much radiation you will be capturing at a particular tilt. Comparison graph between fixed tilt and 2-axis tracker panels.

Whats left to do now is plot yearly solar radiation data.

Sum up all the radiation for a day

iterate through all the days of the year and plot the result.

Find the best fixed tilt angle that will capture the maximum radiation through out the year.

I will be needing up with programming the for loop pretty soon.

10-05-2010
04:46 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-05-2010
04:46 PM

I just skimmed a paper on the PSA algorithm, and found this curious bit..."A direct comparison of the speed of both algorithms is not straightforward, since they are implemented in entirely different computer languages. However because of the fact that the PSA algorithm has slightly more arithmetic operations than the Michalsky algorithm, but fewer if-statements, trigonometric and module operations, it should run faster than Michalsky’s, since the latter are computationally more expensive than the former."

IMO, this doesn't belong in a scientific paper because it is conjecture, and I am inclined to think that it is wrong. It is easy to translate an algorithm this simple from Fortran to C, so the comparison could be made. In addition, "slightly more arithmetic operations" is really 35/28 and 36/25 more, which I don't consider "slight" in light of the number of trig conversions and conditional branches and the percentage of time that the branch is executed. Assuming that the 8 if statements execute one arithmetic op, that is not enough to cover both 7+11 more arith ops in the PSA algorithm. All that being said, it looks as if the PSA algorithm is better than the rest by a useful margin.

Oh, and if the author were concerned with optimization, he might not have used a macro for twopi, because that just substitues 2*pi into the equation, not the calculated result of 2*pi.

~R~

10-05-2010
08:39 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-05-2010
08:39 PM

Can you post the link to PSA algorithm paper. I couldn't find the paper.

BTW take a look at the NREL SPA algorithm (google it). It's 100 times more complicated than the PSA algorithm but is accurate to within 0.0003 degrees.

10-05-2010
09:07 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-05-2010
09:07 PM

Wow, you have done a lot of work in that file. I was wondering how to get the polar plots that you now have at the bottom of the file. They are concave up-is that because they are for the southern hemi?

The link to the paper is...

http://www.psa.es/webesp/index.php

or

www.assembla.com/spaces/sun_follower/documents/d0PIA0oe0r347_eJe5avMc/download/10022519534118276.pdf

~R~

10-06-2010
09:09 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-06-2010
09:09 AM

the sun appears to be south if your are in the northern hemisphere and above tropic of cancer. below it you see that the sun switches sides it appears to come from north. try changing the latitude and see how it affects the graphs.

10-06-2010
11:16 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-06-2010
11:16 AM

there is an updated paper of the PSA algorithm and the authors take a shot at the NREL SPA algorithm as well.

I hope the new PSA paper has information regarding calculating sunrise and sunset based on astronomical refraction at the horizon.

Sadly the paper is behind a payed firewall.

10-24-2011
04:25 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-24-2011
04:25 AM

See the attachment: "**An algorithm for the computation of the solar position**".

10-04-2010
10:07 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Notify Moderator

10-04-2010
10:07 AM

Look at both stack () and augment () and play with them to see how they differ. I'm not sure how you could get a readable effect on a 2D plot, so you might want to go to a 3D plot.

You would then stack or augment multiple calls to PSA_SPC (), then plot the results.

~R~