More investigation is needed.

All capex line items are in the design modules and don't get accounted for if the user foregoes the design module for their own design.

Ideas:

• Move capex line items to the start of the installation phases
• Include capex calculation in both modules and set priority if both are included

TODO:

• Review module documentation against recent changes
• Add example fixed and floating project config files
• Add documentation for outputs available in ProjectManager
• Add documentation for how to use ParametricManager

Move them to process_times and add pathway for optional parameters.

We don't need to do this now, but we could think about adding an argument (and code structure) for # of turbines per substructure. there are some concept designs with 2 tubines on 1 platform.

Originally posted by @Matt-Shields in #15

• Add version that config was generated to for ProjectManager.compile_input_dict().
• Add check for required version in ProjectManager.__init__().

It could be useful to summon the ORBIT turbine library from a python package. This would involve moving the turbine library (https://github.com/WISDEM/ORBIT/tree/dev/library/turbines) to within the installed ORBIT package.

WindIO has suggested a turbine schema which seems well suited for this application: https://github.com/IEAWindTask37/windIO/blob/main/windIO/plant/turbine.yaml. If you wind up hosting this python turbine library, would you be open to using the WindIO schema? We could update it to include the additional fields that ORBIT requires.

I notice that these turbines could be translated into a more refined schema and moved to an installable python package: https://github.com/NREL/turbine-models/. Do you have any interest in including these definitions? It would be straight-forward to translate these data into the windIO turbine schema.

The following two pieces of the custom array design are searching for a project layout in the cables folder. Given the current library structure, I think it might make sense to search for the layout data in project/plant, and to maintain compatibility search for it in cables if it's not found in the project/plant folder.

The primary reason for the requested change is to be compatible with other similar software, such as WOMBAT that use the same library structure for compatibility.

Description

When I run with zero-valued coordinates I get nan values from the CustomArraySystemDesign. This has the effect of leaving the turbines, cables and/or substation(s) out of the plots of the system and also failing in simulation. I have attached the cable layout csv that I was using when I git this error and the resulting layout plot. @RHammond2 helped me figure out what was going on, but the issue is still there. The workaround is of course just using non-zero coordinates.

Error Message

File "/home/anaconda3/envs/env/lib/python3.10/site-packages/marmot/agent.py", line 124, in task
delay = self.env.find_operational_window(ceil(duration), constraints)
File "/home/anaconda3/envs/env/lib/python3.10/site-packages/marmot/environment.py", line 162, in find_operational_window
if not self.state.size > 0:
File "/home/anaconda3/envs/env/lib/python3.10/site-packages/marmot/environment.py", line 111, in state
return self._state[ceil(self.now) :]
ValueError: cannot convert float NaN to integer

Attachments

cable_layout.csv

Caught this when doing an unrelated pull request. The latest version of benedict broke some tests in test_parametric_manager.py. To solve this, just set "python-benedict<0.33.2" in the install_requires list in setup.py.

Verify project capacity gets passed from ProjectManager.

The use of i += string + 1 fails to increment correctly once the number of substations is greater than 2, whereas a simple change of i = string + 1 would correctly account for more than 2 substations.

For instance, with 3 substations and 7 strings on each substation, the value of i at the beginning of each outermost for loop is:

1. 0: correct because it's the initial value for the first substation
2. 7: correct because string 0 on the second substation will 7 strings + 1 to get the 7th index
3. 21: incorrect because string 0 on the third substation should be 14 (2 x (7 strings + 1 for the index adjustment)), and not 7 (starting index) + 13 (index of final string of substation 2) + 1 for the index adjustment. The proposed fix would produce the correct starting index in the matrix creation steps of CustomArraySystemDesign._create_windfarm_layout()

There is a potential issue of the library folder not installing when installing WISDEM via conda.

Someone reached out to me about an issue with the default_library not existing when using a freshly installed version of ORBIT. I don't have any information on the system they're using just that they used a conda installation of WISDEM.

Update: Installing via source does not produce this same issue, only a conda installation is leaving out the library folder.

Currently, the OffshoreSubstationDesign and OffshoreSubstationInstallation only allow a monopile substructure. The code should be improved to include jackets and semisubmersible substructures.

Using the geometry and mass from https://github.com/IEAWindTask37/IEA-22-280-RWT, create a 22MW_generic turbine yaml file and add to the library. Update any tests along the way to ensure that the size/scale of the turbine does not raise any warnings/errors.

and

will result in

If the cable file is updated to:

outputs will work:

Hello,
I think in the 4. Example Fixed Project is a small mistake.
In the "example_fixed_project" file are the Project Inputs (turbine_capex,...) not written in the project_parameters. Instead they are alone. Therefore, they have no impact on the (total) costs.

Hi,

Quite interested in this library but am having trouble looking up documentation on it. This link from the WISDEM library doesn't work, https://orbit-nrel.readthedocs.io/en/latest/. Has the documentation moved?

I did find this paper which is incredibly useful https://www.nrel.gov/docs/fy20osti/77081.pdf, however I am looking for implementation notes and code documentation.

Leaning towards the _defaults.py file in ORBIT.core with different dictionaries for different types of defaults:

• process_times
• costs
• etc.

Logic exists in get_dependency_start_time of the ProjectManager class that raises ValueError if the user specifies a reasonable value. The condition should be replaced with a Warning to notify the user that they specified a value that is not within range, and say why.

Currently, the start time of an installation phase may begin based on some completed percentage of a dependent installation phase. This percentage should be specified between 0.0 and 1.0. However, if the user puts in a value of 1.25 because they wanted the dependent installation phase to start 1.25x after the first installation phase, they will get an error. Furthermore, if the user wants to specify that a phase starts "X days" after another phase, they cannot do this.

Should there be some sort of catch to allow the user to enter the start time based on a percentage of a dependent phase or an integer number of days...

In this line, should subtract twice the thickness to get to the inner diameter.

Credit to WISDEM/WISDEM#398

Expand testing where necessary.

I helped Becca and Sophie debug some odd numbers yesterday and realized during that this configuration is kinda hidden off on it's own. It might make sense to move into the export_system_design sub dict in both the new module and the old one so it's a bit more obvious that it can be modified and has a default value associated with it.

@rrolph575 @amcooperman FYI

Defaults are fixed values based on Cost of Wind Energy Review from ~2019/2020.

First enhancement may be based on methodology in ORCA.

If I specify plant capacity and turbine rating, this overrides the input value of plant capacity and can lead to an extra export cable being created from rounding error stackup.

Example: 600MW plant with 18 MW turbines. Project manager rounds up to 34 turbines; export_system then sizes export cables for 34 x 18 = 612 MW plant. A 220 kV export cable has a rating of 304 MW, so this erroneously adds a third export cable.

Under each of the github workflow files: gh_pages.yml, publish-to-pypi.yaml, and tests.yml all refer to @v2 for checkout and setup-python. They versions should be updated to v4 to avoid workflow complications for different users.