topic Re: Scheduling area of Solar Photovoltaic objects in GDL

[GDL] Scheduling area of Solar Photovoltaic objects

Jim Allen — Tue, 07 Feb 2023 16:51:02 GMT

One thing I have to do on every single project here in the UK is add solar PVs, and Archicad does have a Library object that is pretty good.

However, what is always useful is the ability to quickly calculate the entire area of panels, and calculate an approximate output. Obviously output varies on angle orientation and location, but the range of output within a small geographical area is not that big, enabling a meaningful approximate calculation to be derived.

The benefit of this is that it allows us to roughly work out what sort of PV area we need for any given project. The building services engineers will be able to provide estimates of heating/cooling load and energy requirements, so at an early stage in design we can get an idea of whether net zero carbon is likely to be achievable, and if so, whether we need PVs in places other than the building roof.

The current object Solar Photovoltaic Panel 25 is pretty good, but seems to be a derivation of the Solar Collector Flat Plate 25 object. These are some of the object properties:

Note the FM_HeatOutput property. This is what you would expect with a solar collector. With a PV panel you would expect a power output property.

I would also expect to see a functioning area parameter that allows us to calculate the output in a schedule.

There is one there:

but it has no data.

the Parameter script includes this:

if FM_HeatOutput_unit = `Btu/hour` then hideparameter "FM_HeatOutput" else hideparameter "FM_HeatOutput_btu" endif if FM_RefrigeratingOutput_unit = `Btu/hour` then hideparameter "FM_RefrigeratingOutput" else hideparameter "FM_RefrigeratingOutput_btu" endif if FM_PowerConsump_unit = `W/ft2` then hideparameter "FM_PowerConsumption" else hideparameter "FM_PowerConsumption_feet" endif

That's clearly not right for a photovoltaic panel.

I've tried to open it to see if I could modify it to add an area calculation but the 2D and 3D script dialogs are blank.

We can wait for GS to update this (I reckon it's maybe 10 minutes for someone like Peter 😉) or we can do it - assuming it isn't locked.

Comments, suggestions?

Re: Scheduling area of Solar Photovoltaic objects

Botonis — Fri, 20 Jan 2023 21:47:02 GMT

Maybe I would use property expressions.....

But for a more thorough calculation inside archicad maybe ecodesigner can also do the work

Re: Scheduling area of Solar Photovoltaic objects

Karl Ottenstein — Fri, 20 Jan 2023 22:17:38 GMT

Interesting. Like so many bits in the libraries, the Solar Voltaic Panel has all of the work done in a macro that is called from the Master Script:

If you highlight the name of the macro as I did, and then press cmd-opt-O it will open the macro in a tab and you can see all of the scripts for the solarPanel_m macro. The parameter iSolarObjectType has 3 potential values... where "3" is the photovoltaic panel. Not surprisingly - like most of the primitive and ugly code from Graphisoft - there are no comments within the scripts to tell you what is what, so you have to sort it out yourself...e.g., if iSolarObjectType = 1 then... like how hard was it for the coder to put in a comment to say what a type 1 is? Etc.

Edit: Trial and error placing and opening objects: Solar Collector Flat Plate is type 1; Solar Collector Evacuated Tube is type 2.

Re: Scheduling area of Solar Photovoltaic objects

vistasp — Sat, 21 Jan 2023 12:11:12 GMT

Ooh! I had no idea one could directly open a called macro from the master script of the calling object. Thanks, Karl!

Re: Scheduling area of Solar Photovoltaic objects

Jim Allen — Mon, 23 Jan 2023 11:21:40 GMT

I didn't know about that - thanks!

Could we paste the script into the various script windows to turn it into a 'traditional' GDL object?

Re: Scheduling area of Solar Photovoltaic objects

Jim Allen — Mon, 23 Jan 2023 16:01:18 GMT

There are actually comments in the 3d script.

You are right in that type 3 is the PV panel, and its 3d script is:

! --- Absorber --------------------------------------------------------------------- material "absorber2" addz panel_depth / 2 + glassThk / 4 poly_ 5, glassFrameWidth, glassFrameWidth, 1, panelWidth - glassFrameWidth, glassFrameWidth, 1, panelWidth - glassFrameWidth, panelHeight - glassFrameWidth, 1, glassFrameWidth, panelHeight - glassFrameWidth, 1, glassFrameWidth, glassFrameWidth, -1 base add 0, 0, 0 vert 0, 0, 0 vert 1, 0, 0 vert 0, 1, 0 vert 0, 0, 1 coor 2 + 256, - 1, - 2, - 3, - 4 body 1 del 1 del 1 ! --- End Of Absorber --------------------------------------------------------------------- addy panelHeight next iVert del nPanelVertical addx panelWidth next iHor del nPanelHorizontal

The absorber element is the one that needs the area calculation to be made, and multiplied by the number of panels.

It should be possible to create some new parameters called

PVtotalarea and PVPaneloutput and append some script like:

panelWidth - glassFrameWidth, panelHeight - glassFrameWidth PVwidth = panelWidth - glassFrameWidth PVheight = panelHeight - glassFrameWidth PVarea = PVwidth * PVheight numpanels = nPanelHorizontal * nPanelVertical PVtotalarea = numpanels * PVarea PVtotaloutput = PVtotalarea * PVPaneloutput

shouldn't it?

I've been messing around with the script, but this is way too complicated for my level of GDL knowledge.

There are macros for all sorts of things, including the interface parameters so even adding new ones is not straightforward.

This is so frustrating. I have no idea why one object is scripted in such a way that it contains all the GDL for 3 different variants, which makes the script so much more complicated than it needs to be.

The other thing I don't understand, is why there is no facility built into the component to calculate output based on entered data.

Re: Scheduling area of Solar Photovoltaic objects

Lingwisyer — Tue, 24 Jan 2023 01:07:29 GMT

I do not believe you can total up a parameter in ACs Schedules...

Re: Scheduling area of Solar Photovoltaic objects

Jim Allen — Tue, 24 Jan 2023 10:10:49 GMT

Thanks - that opens up some interesting questions though.

1. What is the best way to deal with things like area/output of PVs with objects?

it's useful to be able to schedule them, but at an early design stage, that's a bit unwieldy. If we are sharing drawings with consultants, a simple label on a drawing to show the PV area/output is arguably the most useful. However at a later stage, with large quantities, scheduling is a more useful tool.

2. Is it possible to link properties and values, and derive one from the other? Suppose we define a parameter for the area, and similar property for the same thing, if they can't be automatically linked, it's not too onerous to manually set the one value to match the calculated one. Unfortunately in the event of changes, we'll end up with inaccurate information. I wonder if this is one area where say a Python script might be able to provide missing functionality.

This is one area where GS could have done with some involvement from practising professionals. It would be useful to understand what the functional requirements of these objects are, and how we will use them, when they are developed.

Some objects can help with design development as well as construction documentation.

Re: Scheduling area of Solar Photovoltaic objects

Jim Allen — Tue, 07 Feb 2023 15:31:17 GMT

I have spent a little time trying to dig into this a little more.

The object contains the following parameters:

They are in the Parameter window and look like this:

I added a line in the Master script pane that looks like this:

ac_collector_area = (panelWidth*panelHeight) * (nPanelHorizontal*nPanelVertical)

Then I opened the macro and entered the line in the Master script pane for that too.

But it didn't work with either option. The Collector Area field is blank. I'm obviously doing something wrong, I just don't know what.

It ought to be really simple to calculate the overall area, and then use the notional input for panel output to derive an indicative potential overall output.

This would be genuinely useful data, that would be able to be scheduled.

Any ideas?

Re: [GDL] Scheduling area of Solar Photovoltaic objects

Peter Baksa — Wed, 08 Feb 2023 07:58:56 GMT

Hi,

The parameters on the description page are a general set of parameters for all mechanical objects. FM_PowerConsumption with description "Wattage" has a negative default value which can be interpreted as output.

If you are going to modify the object, the ac_collector_area calculation can be done in the object too, it doesn't have to be in the macro. You need the parameters command to store the calculated value. Library parameters can be summed in IES.

If you are solving this with properties, look at property expressions. These can do basic calculations with other properties and element settings. They also access object width and length, but no other GDL parameters.

Re: [GDL] Scheduling area of Solar Photovoltaic objects

Jim Allen — Wed, 08 Feb 2023 11:39:16 GMT

Thanks Peter, I thought I was missing something, all it needed was a small tweak to my script line:

PARAMETERS ac_collector_area = (panelWidth*panelHeight) * (nPanelHorizontal*nPanelVertical)

and a couple of others

PARAMETERS ac_collector_area = (panelWidth*panelHeight) * (nPanelHorizontal*nPanelVertical)

PARAMETERS FM_HeatOutput = ac_collector_area * FM_PowerConsumption

! FM_HeatOutput parameter renamed as Output per panel (m2) parameter and used for indicative PV output in W/m2

! FM_PowerConsumption renamed as Indicative electricity output (W/m2) and used to enter estimated electricity generated

I have repurposed and relabelled some of the other parameters to calculate the indicative panel output (based on an estimated input parameter for the output in terms of W/m2 for a particular locality) which is really useful as a rule of thumb.

I have looked at property expressions, but they only work with properties and a very limited set of parameters. I started to do this, but I needed to use some trigonometry to calculate the area of the inclined panel because the only accessible relevant parameters are the 2d footprint and overall height.

These tweaks work perfectly in a schedule, and I can just add objects and with an estimated figure for electricity consumption from engineers for the building (to meet climate change targets in Northern Europe we are going to be moving to reducing consumption with electric heating with renewables) and get a rough idea of how close we can get to net zero at an early design stage.

It's much easier to change parameters in the GDL script.