.hor Files In Pv*sol

[bernard]

Dear PV*SOL community,

 

I have a PVsys horizon profile file (.hor). Basically it's a text file containing pairs of Azimuth-Height values per each line. Height represents the value of the highest obstacle at certain Azimuth (Azimuths are direction from 0 to 360). Those obstacles, can be anything: buildings, trees, mountains...

 

PVsys does not possess the ability of using Tree Transmitance values, so each tree is considered to be an opaque obstacle. On the other hand it looks like PV*SOL does possess this important feature by using Tree's Transmitance values.

 

My first question is:

When importing any sort of horizon file into PV*SOL, how does PV*SOL distinguish between an opaque and partly transparent obstacles? Partly transparent obstacles being the trees.

 

If it does not (meaning: it threats all of them as opaque obstacles), how does PV*SOL horizon files account for the Tree's Transmitance values?


Thank you for the reply in advance.

Bernard

[developer_mh]

Dear Bernard,

 

thank you for your interesting question. The hor files only contain the horizon line value pairs. That is, those values only apply for shading objects that are far away from your pv system (=horizon or very distant houses or the like). The horizon line always has a transmittance of 0%.

 

For near shading objects like trees you should not use hor files, but real 3D objects instead. In the 3D planning environment in PV*SOL premium you can choose from several objects like chimneys, walls and said trees. Those trees can have custom transmission factors.

 

The difference between the shading by the horizon line and the near shading objects is that if the sun is behind the horizon line, there is only diffuse irradiance. There is also no shadow caused by direct sunlight since there is no direct sunlight anymore.

 

Near shading objects however can cast a hard shadow on the pv system, depending on the sun's position and the geometries of the object and the pv systems. Those shadows can lead to important changes to the I-V characteristics when parts of the pv system receive full irradiance and others only the diffuse fraction (as described here: https://help.valentin-software.com/pvsol/2018/calculation/pv-field/ ).

 

Hope that helps,

Martin

[bernard]

Dear Martin,

Thank you for the informative reply.

Would you mind if I ask another question please?

I understand that horizon files (.hor) have very simple structure consisted of Azimuth-Height pairs, which can be manually written to any text file.

But does PV*SOL have an ability to generate its own .hor files, or can it only import externally created .hor files?

[developer_mh]

Dear Bernard,

 

unfortunately this is not directly possible, no. But you could do the following:

• copy the data of the horizon line table to the clipboard,
• paste it in Excel
• subtract 180 from the azimuth values
• copy both azimuth and height values to a text file
• use space as a value separator
• save the file as *.hor

Of course this would only include the horizon line and no near objects. May I ask the use case for the hor-export function? Perhaps we should consider implementing it in the future.

 

Thanks,

Martin

[bernard]

Hi Martin,

Once again thank you for the reply.
Would you mind if I ask you to explain this:

 

 

 

subtract 180 from the azimuth values

Does this mean that PV*SOL .hor files only use Azimuth values from -180 to 180 (instead of from 0 to 360)?

Also can I have comments in my .hor files, and are comments restricted to only the first line of the .hor file? Or PV*SOL accepts comments in .hor's second, third, fourth line as well?
The comments will basically be information about horizon's location, latitude, longitude, altitude...

 

 

 

 

May I ask the use case for the hor-export function? Perhaps we should consider implementing it in the future.

I haven't been using PV*SOL up until now, but from what I can see by looking at your v6 manual, it has some amazing abilities when it comes to shading, which some of your competitors do not (I won't post names). I think it could be beneficial for the PV*SOL to export .hor files, so that other applications could use those too. It's just a suggestion.
But if you think that in this way, those other applications would benefit too much from PV*SOL's ability to export .hor files, then I will take back my suggestion.

[developer_mh]

Hi again,

 

yes, all hor files use azimuth values from -180 to 180. It is kind of a standard, since horizon tools like the SunEye also use this definition. And you can have comments wherever you want, lines that don't contain a valid value pair are just ignored.

 

When you think, PV*SOL Expert 6.0 had amazing abilities, we appreciate that, but you should really take a look at the new PV*SOL premium 2016 The Expert version 6.0 is three years old now, and we made huge improvements since then. See our changelogs and feature descriptions here:

 

http://www.valentin-software.com/en/products/photovoltaics/57/pvsol-premium

 

You can also try the new versions for free.

 

Kind regards,

Martin

[bernard]

Dear Martin,

Thank you again for the reply. I did not know I can use PV*SOL 2016 in demo mode! This is truly a valuable information!

So Azimuths in PV*SOL .hor files are labeled from -180 to 179? Or from -180 to 180?

I am confused because both -180 and 180 show the same Azimuth. So it would be more logical for them to start at -180 and end at -179?
 

 

yes, all hor files use azimuth values from -180 to 180. It is kind of a standard, since horizon tools like the SunEye also use this definition. And you can have comments wherever you want, lines that don't contain a valid value pair are just ignored.

I was lucky enough to have a chance to use SunEye 210 for at least a day, last year.
Indeed it can output .hor files, and it supported outputting a PV*SOL .hor file also.
However I noticed an interesting thing: SunEye threats all objects on its sunpath as opaque. Mountains, buildings and trees, there are all opaque objects. With this in mind, a .hor file generated from SunEye can be beneficial for PV software packages which do not account for trees transmittance indices.
However, as PV*SOL does accounts for trees transmittance indices, it means that a PV*SOL .hor file created from SunEye is invalid. As it will threat the trees to be non-transparent obstacles.

There seems to be a way of fixing this issue by actually erasing the trees from the SunEye sun path diagram.

[developer_mh]

Hi Bernard,

 

yes, you are right, the azimuth values in the hor file only need to go from -180 to 179. If you provide a value for 180°, it will be ignored. Thanks for the correction!

 

Also, you don't necessarily have to provide all data points from -180 to 179, you can also just provide some arbitrary value pairs in between that range. This for example would also be a valid hor file:

# comment line
This is also a comment line
-180 0
-133 13
-117 6
a comment somewhere else
-94 2
-17 4
19 7
62 7
101 1
144 7
171 6

And your remark about the horizon line captured by the SunEye is absolutely correct, of course. Near shading objects need to be excluded, if you are in 3D mode of PV*SOL premium, since you will place those near objects there. Thanks for pointing that out and for providing the link to the user guide.

[bernard]

Martin,

That .hor file example perfectly cleared all my doubts!

And thank you for the explanation on SunEye's exclusion of near shading objects.

I do not know about other persons from Valentin software, but by judging from this topic, they seem to have a very reliable support team.

Once again thank you, and have a nice day.

[developer_mh]

Thanks, that is nice to hear

[bernard]

Hi Martin,

I was wondering if you could just answer to one more question please?
The question may sound strange, I apologize for that in advance, but:
Would PV*SOL accept a text file consisted of pairs of azimuths and heights where azimuths are presented as decimal values, instead of integers?

For example:
 

-180 2

-179.9 10

-179.8 31

...

178.7 12

178.8 5

178.9 18

179 20

 

?

I perfectly understand that taking azimuth angles increment of 0.1 is redundant.
Still I am just curious if it will work in PV*SOL?

Will PV*SOL be able to import these decimal azimuth values?

Thank you.

[developer_mh]

Hi Bernard,

 

thanks for your question! Azimuth values with decimal point will be ignored when you import the file. So in your example, only those two value pairs would be imported:

-180 2
179 20

Cheers,

Martin

[bernard]

Dear Martin.

Again, thank you for the quick reply.

Kind Regards,
Bernard