Conversation
…Add functions to sweep ofo parameters, sweep DC locations, find DC hosting capacity, and optimize PV locations and capacities. Add IEEE 13, 34, 123 test feeders and example scripts. Include simulation outputs for IEEE 13, 34, 123 under multiple scenarios.
…Add functions to sweep ofo parameters, sweep DC locations, find DC hosting capacity, and optimize PV locations and capacities. Add IEEE 13, 34, 123 test feeders and example scripts. Include simulation outputs for IEEE 13, 34, 123 under multiple scenarios.
|
Please remove all output files that can be generated from running the examples. Data files do not belong in the code repository except when it's necessary for examples to run. |
|
Also, please update code so that formatting, code checking, and testing pass. You can run them with bash scripts/lint.sh and pytest. In general, I would back up a copy of the dir elsewhere so that you don't lose any files, and then ask claude code to clean up the branch so that it's suitable to post a PR. |
jaywonchung
left a comment
jaywonchung
left a comment
There was a problem hiding this comment.
Thank you for your work. This PR will mark a substantial advancement in what OpenG2G an do!
There are many structural issues -- please take your time to address them, and please let me know if anything is unclear.
There was a problem hiding this comment.
This is a general comment/question about all OpenDSS case files in data/grid.
data/gridwas newly created, andexamples/ieee13was moved into it. However, I thought what used to be inexamples/ieee13were already customized by you and is no longer the same as what people would expect as the standard IEEE13 bus specification. That's why I put it underexamples(to indicate that its specific to the baselines & OFO examples), notdata(which lacks context & connection to our customization). What is the nature of these files? What do you think is the right place for this so that users are not misled?- All file extensions should be
.dss. Currently, it's a mixture of.dssand.DSS. - IEEE13 has a CSV file (
IEEE13Node_BusXY.csv) whereas the other two do not. Also, file names are all inconsistent, except forIEEELineCodes.dss. Is it possible to make things consistent? Unless, if this is how each case is shipped officially, or each case is quite different and making file organization consistent is actually impossible/harmful for usablity.
There was a problem hiding this comment.
- I think you'll need to update
_zensical.tomlto include these example guides as a new section -- basically "Getting Started," "Guide," "Examples," and "API Reference" in order. - Please remove the number prefix in the beginning of each example description markdown file. These numbers will be shown in the documentation website's URL and signals that there is an ordering of examples, but in fact, I don't think the examples have any particularly natural ordering.
- Please preview the documentation on your browser after running
bash scripts/docs.sh serveand see if everything is rendered properly (e.g., no Markdown issues, links are all working).
There was a problem hiding this comment.
I think this should be removed for now. We never tested it.
| ) | ||
| ``` | ||
|
|
||
| #### Inference Ramps |
There was a problem hiding this comment.
I don't think InferenceRamp is complicated enough to require a dedicated section in the docs. Same as now TrainingRun, TapPosition, etc. are not separately explained -- the API reference is likely sufficient. In general, we want to control the length of the guides in docs, because the longer it is, the less likely people will actually read it. Please delete this section.
|
|
||
| - **`target`**: Fraction of initial servers to activate. `0.5` = half the servers; `1.0` = all servers (default); `1.5` = 50% more servers than the initial `initial_num_replicas`. | ||
| - **`model`**: When set, the ramp applies only to that model. When `None` (default), it applies to all models in the datacenter. | ||
| - **Scale-up** (target > 1.0): The datacenter pre-allocates extra servers at construction time based on the peak target in the schedule. At `t=0`, only the initial server count is active; the extra servers activate when the fraction exceeds 1.0. |
There was a problem hiding this comment.
I was reading this an I think this API is weird. 1.0 (meaning 100%) should be a fixed ceiling. I don't think we want a constantly moving ceiling. For that, I think InferenceRamp(target=0.5).at(t=0) (with composition with |) is the right API. This way, we're specifying (time, target load) points across the whole timeline and we don't have to do this dynamic ceiling adjustment at all. Please refactor InferenceRamp.
| Attributes: | ||
| dc_states: Every datacenter state produced by the datacenter. | ||
| dc_states: Every datacenter state produced by the datacenter (flat list, all sites). | ||
| dc_states_by_site: Per-site datacenter states (multi-DC mode). |
There was a problem hiding this comment.
Multiple DC should be a generalization of the original single DC. That is, single DC mode should be programmatically equivalent to multiple DC mode, except that there is only one DC site. Not touching the original single DC code and data path and slapping on multi-DC code and data on top of it is poor design.
| # For 3-phase regulators without explicit phase suffix, | ||
| # try to infer phase from the regcontrol name (e.g. creg1a -> A=1) | ||
| if phase not in (1, 2, 3): | ||
| name_lower = rc_name.lower() | ||
| if name_lower.endswith("a"): | ||
| phase = 1 | ||
| elif name_lower.endswith("b"): | ||
| phase = 2 | ||
| elif name_lower.endswith("c"): | ||
| phase = 3 | ||
| elif n_phases == 3: | ||
| # 3-phase ganged regulator — assign to phase 1 as primary | ||
| phase = 1 | ||
| logger.info( | ||
| "RegControl '%s' is 3-phase (buses=%s); treating as phase A.", | ||
| rc_name, | ||
| bus_names, | ||
| ) | ||
|
|
There was a problem hiding this comment.
Matching based on arbitrary string name patterns is highly error prone. Please make it type safe by generalizing the original pattern of having fields a, b, and c.
| a: float | None = None | ||
| b: float | None = None | ||
| c: float | None = None | ||
| regulators: dict[str, float] = field(default_factory=dict) |
There was a problem hiding this comment.
Same complaint. Generalizing single -> multi should be a type-safe structural shift, not spraying escape hatch dicts on top of existing APIs that were built assuming single.
| Supports both single-DC (legacy) and multi-DC modes: | ||
|
|
||
| - **Single-DC**: Pass ``dc_bus``, ``dc_bus_kv``, ``connection_type``. | ||
| - **Multi-DC**: Pass ``dc_loads`` dict mapping site IDs to | ||
| :class:`DCLoadSpec`. | ||
|
|
There was a problem hiding this comment.
Many changes were made to the offline datacenter. Please review feature parity between the offline and online datacenters. For instance,
- Did some new feature get introduced in offline datacenter but it's not handled by the online datacenter although it can be handled?
- Did some configuration class change for a feature to be introduced in the offline datacenter, but the online datacenter silently ignores that configuration or even worse, error out?
- The offlien and online datacenters used to share a lot of behavior between each other by sharing a lot of code paths. Did any assumptions based on shared codebase and behavior change only in offline and not updated in online?
2 participants
Include all the latest example scripts and results for report writing.