Use pvlib for PV Model - Githubissues

mnblonsky commented 1 year ago

Just tried running SAM v4.0 within OCHRE and it failed:

pvsamv1 simulation error
        : precheck input: variable 'subarray1_rear_soiling_loss' (Sub-array 1 rear soiling loss) required but not assigned

reset to 3.0.1 and it works. We should mention this in the documentation and update so it works with the latest PySAM. Or move to pvlib...

mnblonsky commented 1 year ago

pvlib seems like a much better choice at this point.

jmaguire1 commented 1 year ago

@mnblonsky and @jmaguire1 to discuss w/ SAM team next week.

jason-curtis commented 1 year ago

Is there a recommended path to model PV in OCHRE for the time being? I've done the following:

ran pip install NREL-PySAM==3.0.2 to get past the error above
start with this example code

Download a SAM CSV using the following code:

SAM_WEATHER_FILENAME = "sam_solar_data.csv"
sam_solar_data, sam_solar_metadata = pvlib.iotools.get_psm3(
latitude, longitude, NREL_API_KEY, NREL_API_EMAIL, map_variables=True
)
sam_solar_data.to_csv(SAM_WEATHER_FILENAME, index=False)

uncommented the PV section under dwelling_args['equipment']:

    'PV': {
        'use_sam': True,
        'capacity': 5,
        'tilt': 20,
        'azimuth': 180,
        'sam_weather_file': SAM_WEATHER_FILENAME, # This is the key documented at https://ochre-docs-final.readthedocs.io/en/latest/InputsAndArguments.html#solar-pv but doesn't appear used
        'equipment_schedule_file': SAM_WEATHER_FILENAME, # This is what the code seems to look at
    },

But I'm still running into walls - most recently pvsamv1 simulation error: exec fail(pvsamv1): latitude and longitude required but not specified.

Do you recommend not modeling solar in OCHRE currently, or is there a recommended way to do it?

mnblonsky commented 1 year ago

Hi @jason-curtis, you're right that the equipment_schedule_file will currently overwrite any data that SAM generates. I think that's something we should change in the future.

The sam_weather_file is actually a file path that OCHRE will use to save data for SAM, so OCHRE will overwrite anything in that file. There's also a default, so you don't need to specify it.

We haven't run SAM with OCHRE in a while, so it looks like there are a few bugs for us to fix. For now, I would recommend that you run SAM separately and get a time series PV power profile, and then save that to the equipment_schedule_file. You'll need to change the heading so the power column is called "PV (kW)". OCHRE will use that column to set the PV power at each time step. No need to specify any other inputs, though you can use schedule_rename_columns to automatically change the power column name or schedule_scale_factor to automatically change the units.

Normally, the recommended way to run with PV is to only specify capacity in the PV dictionary. That's the only required input. However, it doesn't look like this is working in the latest version of OCHRE. I'll work on a fix for this soon.

jason-curtis commented 1 year ago

Got it, thanks for the response. I already have pvlib set up for my location so I will try and generate a schedule file from that.

On Thu, Nov 9, 2023 at 6:52 AM Michael Blonsky @.***> wrote:

Hi @jason-curtis https://github.com/jason-curtis, you're right that the equipment_schedule_file will currently overwrite any data that SAM generates. I think that's something we should change in the future.

The sam_weather_file is actually a file path that OCHRE will use to save data for SAM, so OCHRE will overwrite anything in that file. There's also a default, so you don't need to specify it.

We haven't run SAM with OCHRE in a while, so it looks like there are a few bugs for us to fix. For now, I would recommend that you run SAM separately and get a time series PV power profile, and then save that to the equipment_schedule_file. You'll need to change the heading so the power column is called "PV (kW)". OCHRE will use that column to set the PV power at each time step. No need to specify any other inputs, though you can use schedule_rename_columns to automatically change the power column name or schedule_scale_factor to automatically change the units.

Normally, the recommended way to run with PV is to only specify capacity in the PV dictionary. That's the only required input https://ochre-docs-final.readthedocs.io/en/latest/InputsAndArguments.html#solar-pv. However, it doesn't look like this is working in the latest version of OCHRE. I'll work on a fix for this soon.

— Reply to this email directly, view it on GitHub https://github.com/NREL/OCHRE/issues/1#issuecomment-1803980036, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZPVU6JOU7CP4U4Q2AOHXTYDTU2XAVCNFSM6AAAAAA2BB4CWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBTHE4DAMBTGY . You are receiving this because you were mentioned.Message ID: @.***>

jason-curtis commented 1 year ago

OK, I passed in a CSV file under dwelling_args['equipment']['PV']['equipment_schedule_file'] but it seems if I give an inch, OCHRE takes a mile. Is there a way to only pass a PV schedule and not a schedule for everything else:

Exception                                 Traceback (most recent call last)
/tmp/ipykernel_12/4174122461.py in <cell line: 98>()
     98 if __name__ == '__main__':
     99     # Initialization
--> 100     dwelling = Dwelling(**dwelling_args)
    101 
    102     # Simulation

~/.cache/pypoetry/virtualenvs/python-kernel-OtKFaj5M-py3.9/lib/python3.9/site-packages/ochre/Dwelling.py in __init__(self, metrics_verbosity, save_schedule_columns, save_args_to_json, **house_args)
     72 
     73         # Load occupancy schedule and weather files
---> 74         schedule, location = load_schedule(properties, weather_station=weather_station, **house_args)
     75         properties['location'] = location
     76         self.start_time = self.start_time.replace(tzinfo=schedule.index.tzinfo)

~/.cache/pypoetry/virtualenvs/python-kernel-OtKFaj5M-py3.9/lib/python3.9/site-packages/ochre/utils/schedule.py in load_schedule(properties, schedule, time_zone, **house_args)
    621         bad_cols = check.columns[check.isna().any()]
    622         first_na = check.isna().any(axis=1).idxmax()
--> 623         raise Exception(f'Missing data found in schedule columns {bad_cols}. See time step {first_na}')
    624 
    625     # update time zone, if specified

Exception: Missing data found in schedule columns Index(['Ambient Dry Bulb (C)', 'Ambient Relative Humidity (-)',
       'Ambient Pressure (kPa)', 'GHI (W/m^2)', 'DNI (W/m^2)', 'DHI (W/m^2)',
       'Wind Speed (m/s)', 'Mains Temperature (C)', 'Ground Temperature (C)',
       'Ambient Humidity Ratio (-)', 'Ambient Wet Bulb (-)',
       'Occupancy (Persons)', 'Indoor Lighting (kW)', 'Cooking Range (kW)',
       'Cooking Range (therms/hour)', 'Dishwasher (kW)', 'Clothes Washer (kW)',
       'Clothes Dryer (kW)', 'Clothes Dryer (therms/hour)', 'MELs (kW)',
       'Dishwasher (L/min)', 'Clothes Washer (L/min)', 'Water Heating (L/min)',
       'Basement Lighting (kW)', 'Water Heating Setpoint (C)',
       'Refrigerator (kW)', 'Exterior Lighting (kW)',
       'HVAC Heating Setpoint (C)', 'HVAC Cooling Setpoint (C)'],
      dtype='object'). See time step 2022-01-01 00:30:00

If it helps, this is the PV file I'm passing: https://gist.github.com/jason-curtis/9c75794fb6c32b8cecc74f936cfb44dd . I've tried with and without a timestamp column, with the same results.

Apologies if this is off topic, lmk if I should file a separate issue.

mnblonsky commented 1 year ago

That's very strange... It looks like maybe you included something in dwelling_args['schedule']? Try removing that if you have something in there.

jason-curtis commented 1 year ago

Nothing in schedule, but the https://github.com/NREL/OCHRE/blob/main/bin/run_dwelling.py example has a schedule_input_file.

I just realized I had another issue where I changed the timestep, and now the schedule_input_file probably doesn't have the correct number of rows.

In any case, I'm taking a non-OCHRE approach for the moment and I'll keep an eye on this issue for when pvlib is integrated.

In the unlikely event that I end up with spare time on this, would you accept a PR for removing the PySAM integration and using pvlib instead? It's been pretty easy to work with!

mnblonsky commented 1 year ago

Ok. The schedule_input_file should really come from ResStock or BEopt, and has to have data for a whole year (I haven't tested otherwise, but I'm pretty sure that won't work).

Yes, it'd be great if you wanted to help with the development of pvlib! We did recently learn that PySAM can do single step updates, so we may stick with it long term, but we haven't made that decision yet. One possible advantage of PySAM over pvlib is that I think it has more features related to inverter modeling and DC-coupled PV+battery, so we may prefer that route. We'll hopefully get to that in 2024.

mnblonsky commented 9 months ago

We plan to use PySAM v5.0 instead of switching to pvlib. The new version of PySAM has a few useful features, including direct implementation of PVWatts (which will be the default) and the ability to run single time steps.

We're also removing the sam_weather_file, which caused some issues in the past.

jmaguire1 commented 9 months ago

Nice! Glad you can run a single timestep now, that's a big change for our use case. And I'd rather use an NREL tool than pvlib if possible.

This might also set us up in the future to use SAM for utility bills? I know it has a bill calculation module that can load rates from the URDB, I think (but not 100%) we do this for OS-HPXML. At one point a long time ago I wrote my own bill calculation methodology (in python for BEopt 2.x) but I'd rather rely on SAM in case we hit any complicated cases (like say TOU + tiered + PV without net metering).

NREL / OCHRE

Use pvlib for PV Model #1