run-llama/llama_cloud_services
1
0
Fork 0
mirror of https://github.com/run-llama/llama_cloud_services.git synced 2026-08-26 16:56:36 -04:00
Code Issues 352 Packages Projects Releases 10 Wiki Activity

Number Parsing PVSyst Diagrams #223

New Issue
Closed
opened 2026-02-16 00:17:11 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 00:17:11 -05:00
Owner
Copy Link
Copy Source

Originally created by @t-kwasnik on GitHub (Aug 5, 2024).

Incorrect Parsing of Loss Values

This link shows a file with a PVSyst Loss Parameters diagram on page 13.

Screenshot 2024-08-05 at 7 55 30 AM

Lllamaparse is consistently returning Global incident in collection plane as -4.39% (should be -4.3)
Lllamaparse is also consistently returning Near Shadings: irradiance loss as 22.19% (should be -2.1%)

Overall, it appears the % symbols can cause an extra 9 to appear at the end of parsed values. Also a leading negative sign seems to result in duplicating the first number (at least when it starts with a 2).

Parsing Instructions (sent just page 13)

This is a PVSyst file. It contains information about energy losses during solar PV generation. It is a graphic that has a table structure.

There are 3 types of terms on the page:
 Group A - on the far left there are numbers with units (# kWh, # kWh/sqw meter) or conversion equations ( term = #% )
 Group B  - To the middle and middle left are "loss terms". Losses are in the format: (+ #.# %) or (+ #.# %) 
 Group C - Labels on the right sight of the page for Group A and B values.

Match Group C labels with Group A and B values

Group B OVERRIDES
    - a loss term will always start with a "+" or "-", a "-" may appear to be "~" so correct this mistake
    - the last character in a "loss term" may appear to be a "9", if the term has two decimal places, replace the last "9" with a "%"

Do not include any values in the response that are not in the source.
Originally created by @t-kwasnik on GitHub (Aug 5, 2024). ## Incorrect Parsing of Loss Values This [link](https://knowledge-center.solaredge.com/sites/kc/files/designing-se-with-pvsyst.pdf) shows a file with a PVSyst Loss Parameters diagram on page 13. <img width="579" alt="Screenshot 2024-08-05 at 7 55 30 AM" src="https://github.com/user-attachments/assets/06d1e08a-2198-42b6-8bec-9bf7367928d4"> Lllamaparse is consistently returning **Global incident in collection plane** as `-4.39%` (should be `-4.3`) Lllamaparse is also consistently returning **Near Shadings: irradiance loss** as `22.19%` (should be `-2.1%`) Overall, it appears the % symbols can cause an extra 9 to appear at the end of parsed values. Also a leading negative sign seems to result in duplicating the first number (at least when it starts with a 2). ## Parsing Instructions (sent just page 13) ``` This is a PVSyst file. It contains information about energy losses during solar PV generation. It is a graphic that has a table structure. There are 3 types of terms on the page: Group A - on the far left there are numbers with units (# kWh, # kWh/sqw meter) or conversion equations ( term = #% ) Group B - To the middle and middle left are "loss terms". Losses are in the format: (+ #.# %) or (+ #.# %) Group C - Labels on the right sight of the page for Group A and B values. Match Group C labels with Group A and B values Group B OVERRIDES - a loss term will always start with a "+" or "-", a "-" may appear to be "~" so correct this mistake - the last character in a "loss term" may appear to be a "9", if the term has two decimal places, replace the last "9" with a "%" Do not include any values in the response that are not in the source. ```
yindo closed this issue 2026-02-16 00:17:11 -05:00
yindo commented 2026-02-16 00:17:11 -05:00
Author
Owner
Copy Link
Copy Source

@BinaryBrain commented on GitHub (Aug 8, 2024):

You're correct. Our OCR is not perfect and we're looking to improve it. In the meantime, you could try with the multimodal approach, which seems to give better results:


| Parameter                  | Value  | Description                                     |
| -------------------------- | ------ | ----------------------------------------------- |
| 880 kWh/m²                 |        | Global horizontal irradiation                   |
|                            | +20.0% | Global incident in coll. plane                  |
|                            | -4.3%  | Near Shadings: irradiance loss                  |
|                            | -2.1%  | IAM factor on global                            |
|                            | -2.0%  | Soiling loss factor                             |
| 970 kWh/m² \* 810 m² coll. |        | Effective irradiation on collectors             |
| efficiency at STC = 19.79% |        | PV conversion                                   |
| 155464 kWh                 |        | Array nominal energy (at STC effic.)            |
|                            | -0.2%  | Module Degradation Loss ( for year #1)          |
|                            | -0.9%  | PV loss due to irradiance level                 |
|                            | -1.8%  | PV loss due to temperature                      |
|                            | -1.3%  | Shadings: Electrical Loss detailed module calc. |
|                            | -0.9%  | Optimizer efficiency loss                       |
|                            | +0.4%  | Module quality loss                             |
|                            | -2.0%  | LID - Light induced degradation                 |
|                            | 0.0%   | Module array mismatch loss                      |
|                            | -0.7%  | Ohmic wiring loss                               |
| 144149 kWh                 |        | Array virtual energy at MPP                     |
|                            | -1.7%  | Inverter Loss during operation (efficiency)     |
|                            | -0.4%  | Inverter Loss over nominal inv. power           |
|                            | 0.0%   | Inverter Loss due to max. input current         |
|                            | 0.0%   | Inverter Loss over nominal inv. voltage         |
|                            | 0.0%   | Inverter Loss due to power threshold            |
|                            | 0.0%   | Inverter Loss due to voltage threshold          |
| 141160 kWh                 |        | Available Energy at Inverter Output             |
|                            | -0.4%  | AC ohmic loss                                   |
|                            | -1.4%  | Medium voltage transfo loss                     |
|                            | 0.0%   | MV line ohmic loss                              |
| 138604 kWh                 |        | Energy injected into grid                       |

pvsyst-13.md

I'm closing this bug as it's a duplicate of other OCR-related issues and it's in our backlog.

@BinaryBrain commented on GitHub (Aug 8, 2024): You're correct. Our OCR is not perfect and we're looking to improve it. In the meantime, you could try with the multimodal approach, which seems to give better results: ```md | Parameter | Value | Description | | -------------------------- | ------ | ----------------------------------------------- | | 880 kWh/m² | | Global horizontal irradiation | | | +20.0% | Global incident in coll. plane | | | -4.3% | Near Shadings: irradiance loss | | | -2.1% | IAM factor on global | | | -2.0% | Soiling loss factor | | 970 kWh/m² \* 810 m² coll. | | Effective irradiation on collectors | | efficiency at STC = 19.79% | | PV conversion | | 155464 kWh | | Array nominal energy (at STC effic.) | | | -0.2% | Module Degradation Loss ( for year #1) | | | -0.9% | PV loss due to irradiance level | | | -1.8% | PV loss due to temperature | | | -1.3% | Shadings: Electrical Loss detailed module calc. | | | -0.9% | Optimizer efficiency loss | | | +0.4% | Module quality loss | | | -2.0% | LID - Light induced degradation | | | 0.0% | Module array mismatch loss | | | -0.7% | Ohmic wiring loss | | 144149 kWh | | Array virtual energy at MPP | | | -1.7% | Inverter Loss during operation (efficiency) | | | -0.4% | Inverter Loss over nominal inv. power | | | 0.0% | Inverter Loss due to max. input current | | | 0.0% | Inverter Loss over nominal inv. voltage | | | 0.0% | Inverter Loss due to power threshold | | | 0.0% | Inverter Loss due to voltage threshold | | 141160 kWh | | Available Energy at Inverter Output | | | -0.4% | AC ohmic loss | | | -1.4% | Medium voltage transfo loss | | | 0.0% | MV line ohmic loss | | 138604 kWh | | Energy injected into grid | ``` [pvsyst-13.md](https://github.com/user-attachments/files/16549238/pvsyst-13.md) I'm closing this bug as it's a duplicate of other OCR-related issues and it's in our backlog.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
LlamaCloud
LlamaExtract
LlamaParse
bug
client
complex layout
documentation
duplicate
enhancement
figure
font
header footer
help wanted
ocr
parser
pdf_debug
pdf_debug
pull-request
Mirrored from GitHub Pull Request
 python-lib
question
server_issue
server_issue
ui
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: run-llama/llama_cloud_services#223
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?