Well, I come everybody.
We're going to talk about Sun Peak.
My name is Philip.
This is Marna.
And Sun Peak is about solar thermal plants.
Solar thermal plants.
It's an open source software for performance monitoring
and assessment of such plants.
So why even bother about this?
Well, very simple, right?
Everybody vaguely interested in the future
the future of human kind probably knows this.
Most of our greenhouse gas emissions come from energy.
So we should bother about renewable energy.
What is energy?
Is it just what comes out of the circuit?
Also, but not alone.
Look at about half of our finite energy consumption
is heating and cooling.
So we can do part of that with heat pumps and stuff.
It's good.
Can electrify somethings.
Still, it's half.
Heat is half.
And almost everything of that just 10% to 11%.
Maybe 11.5 now.
12%.
But almost everything is fossil.
So we have a very long way to go.
Every is talking about increasing shares of renewables.
Are we doing good?
Yeah, we are slightly increasing in percent.
But in absolute numbers, we are not.
Look at this 10-year comparison.
In absolute numbers, we are going up.
We should be going down to zero as quickly as possible.
So we have a long way to go.
And there is big potential for lots of technologies.
And solar thermal is one of them.
Solar thermal has very good projections on the long run.
So what is solar thermal?
I guess most of you know PV for the world types by now.
What is it?
It's simply put devices that turn sunlight into electricity.
This is a, maybe a simplified.
But you understand the point.
Solar thermal is what we talk about now.
And it's very different.
It's a very different technology.
It's basically water or some other heat transfer fluid circulating in some collectors.
And thanks to some highly efficient materials and coatings.
It enters cold and it gets out hot.
That's how it works.
It's highly efficient.
It means per square meter, it's about three times as efficient as PV.
Of course, it produces heat.
Now for electricity.
So it's something different.
Producers heat means it's only useful when it produces the temperature level that you need that you want.
So we have a lot of different technologies for different temperature levels, including concentrating, including vacuum, etc.
So you can tell we need a lot of different physical models to describe how all these technologies work.
And this is basically what Sandpick is about.
We focus on large scale systems.
They look more or less like these.
You can tell that there's a lot of different technologies involved.
You can also tell from this picture that Sandpick focuses basically on a B2B level.
So we don't deal with end customers primarily.
It's B2B.
And what we do with these, with these plants.
We are not into designing them.
We're not into installing them.
We come into play when these plants are all out there and being commissioned and start the operation and start collecting data.
Start collecting sensor data.
And then with that sensor data, we try to answer basically two important questions.
One is a verification question.
Does the plant perform as expected?
Well, it performs as it performs, like we measure it with heat meters.
But what is expected?
That's difficult because temperatures are different.
The technologies are different.
Weather is different, et cetera, et cetera.
So the calculating the expected part is the heart part of this question.
And the second is a monitoring question.
Are there any changes over time?
So again, we have very much into the operational phase of these plants.
Why?
Because on the design phase, there is love knowledge.
It's quite well known by now how to build these plants.
There is a lot of well-known and established standards.
On the operational side, there is just one technical standard, which emerged two years ago.
So it's very recent.
And we're basically implementing methods from that ISO standard into our software.
Because we believe that open source software is much more useful than PDF documents.
And we're also active in the technical committee, which developed this ISO 24194.
So to give you a few results of what it roughly does.
Basically, some data filtering.
And then we compare what is measured.
What is measured at the plant level with the target.
So with what some pick, platilates is the expected outcome.
And yeah, if we are above what we expect, then we're doing good.
So we do this for some period of time.
And the measure is more than the target, more than the expected,
than the check is verified.
The check is passed.
The second application of this can be to apply this check over time.
And calculate this ratio of measured to expected.
And then you see when the performance started degrade.
And this is with all influencing factors already factored in already calculated.
So this is not because of differences in weather or radiation and temperature.
That's already factored in in our models.
So a decrease is a decrease.
So in that case, you can tell that something is going wrong at the plant.
Either there is something that doesn't work.
Or like in this simple case, it's just time to clean the collectors.
But it's also very useful to know when it's time to clean the collectors.
Because that costs money, right?
Okay, and before I hand over to you, Marna,
like a proud image that we submitted.
I'll just paper just last week.
So you can find a lot more about more research methods.
That reactive in this was just a very simplified version of all.
And we also share open data and more research papers.
Or in our eyes in order community.
Talking about some communities.
I'll hand over to you.
Marna comes from Scotland and then will explain everything in proper English.
Sorry, Marna.
Right, yes, somewhat unconventionally putting the community slide in the middle of the presentation.
We should mention our funders.
We're funded at the moment mostly by research grants.
We're trying to change that from both EU and Austrian national level as well as some industry foundations.
And we have a small but growing community of users and and.
We say expertise contributors.
We are really trying to grow our also software contributors.
It's something we would very much like more of.
From mostly academia at the moment with one or two industry users.
Yes, so the project was initiated by ourselves as a research institute and then for commercial partners who who operate in the in the space.
So we've been very close to the actual industry for the entire duration of the project.
Right.
Going to a little bit more detail about how.
How this actually works so.
The basic workflow in the software is that you add a solar thermal plant object.
And then you have to describe the properties of that plant.
So both the overall size of the field position.
Various things like that as well as the specific model of collective that you're using.
We include a fairly small database of those at the moment.
We are actively working to integrate it with the.
Sort of European industry standard database of certified solar thermal collectors.
The reason picking a particular collect the model is very important is that that is how we calculate the expected performance.
So that's a key step in every collective forms.
Very significantly differently.
We have a process called sensor mapping.
Basically we try to be as open as possible in what input data we accept.
Because every scatter system, every logging system outputs its own.
Fun different data format with its own channel names.
So rather than requiring our users to reformat all of their data in order to work with our software.
We'll try and take as many different data formats as we feasibly can or at least as many different data layouts as we feasibly can.
So that means we have defined.
Roles is probably the best word for data channels within the software.
And the user has did a one-off process to manually say this channel in my data with this arbitrary name that my control system engineer selected maps to this role.
Upload data sets something called the safety factor, which is something that comes from the standard and is a slightly hand-wave deal with all of the sensor errors and losses from pipes and things factor.
We would very much like to reduce how large that factor has to be and make it more precise, but at the moment it's kind of a requirement.
I was going to go into a little bit more technical detail.
I think for time I will jump over this slide.
And yes, then I was going to go less technical detail and I'm going to architecture.
But I just want to highlight the fact that we took an approach which has led to some slightly interesting packaging decisions and a little bit of complexity on our side.
Of basically we want to support quite a wide range of users from what we deemed technical experts.
So other researchers, other software engineers, people who actually want to work with our call libraries, directly either to integrate them into the software or to integrate them with a web API.
And we also want to support general users from the plant operator companies who are typically not software engineers are typically not IT people in quite a lot of cases are users have an IT staff of zero, which means we need to be quite friendly to them.
So we have a JavaScript front end, which is built as a separate component.
And then our entire back end is in Python, I don't remember mentioned that yet.
And we provide different packaging formats for our different users.
So for the general user case, get it running quickly.
We provide a set of Docker images and a Docker compose file.
And then we also provide a Python package, which is on pipeline if anyone wants to use that.
Yes, again different installation options.
I'll just mention them for completeness on the slide.
We also bundle a set of open data with the application.
So one of our initial contributing cooperating partners contributed some data from one of their plants, which is normally very hard to get people don't like to share their operating data.
So if you install the full application or you install the Python package with the demo extra you get a set of data to play around without having to actually set up your own plan to talk.
And that is also available on we have a public demo server.
Please be aware it is a public demo server any day to upload there is public.
I have big plans in the back of my head to build a sandbox integrated with the documentation that that hasn't happened yet.
Yes, just the last information is available. We have Doc site.
We're on get lab.
We want to join us and yes, please join us.
If anyone is interested as joining as a contributor we will welcome anyone.
I think we have time for questions.
Okay.
So the question was will it work on household sized systems and the answer is no.
Mostly because they tend not to have the right instrumentation.
Yes, and the answer is also yes.
There are more methods that don't even require a lot of instrumentation.
You set the data for methods that we did not present today.
But we not targeting small household.
Why? Because the market is decreasing a lot in small households.
So we deliberately chose large installations because those are used more in industry and district heating applications.
But in theory, a lot of this would also work.
No one just is.
We basically take everything that we can get.
We take all temperature sensors.
And the system for collector fields typically have at least one inlet one outlet temperature sensor.
Sometimes they have one outlet temperature sensor per row.
Because we are different so we need to control volume flows.
We take thermal power output or volume flow or whatever we have.
It was shown on the architecture slide.
We integrate cool prop or interface cool prop.
That's a fluid property database.
We need that to calculate power.
So we need to be flexible because a thermal sector is not very standardized in what we can get.
And now time is up.
Thank you very much.