Sorry for the inconvenience. Can you tell me what eplusr version you are using by running packageVersion("eplusr")?

I submitted eplusr v0.10.0 which includes lots of new functionalities and unfortunately some break changes.

From the error you got, I guess you are using eplusr v0.9.4. The default validation level is final, as stated in the error message. It will prevent you from deleting any objects that are referred by others, because deleting them will introduce invalid field reference. You can switch to validation level none or draft which will disable invalid reference checking when you perform object deletion. You can do this by:

eplusr_option(validate_level = "draft")
# OR
# eplusr_option(validate_level = "none")

# Now you should be able to successfully delete any object
model$del_object(38)

# After deletion, remember to change the validation level back to final
eplusr_option(validate_level = "final")

$del_object() method is deprecated in eplusr v0.10.0 in flavor of the successor $del() method. In v0.10.0, you can also achieve the same thing by changing the validate_level option to draft or none, or you can set .force to TRUE:

model$del(38, .force = TRUE)

from eplusr.

Thank you for your suggestion. I updated the packages but I have extra errors when inputting the weather data: (the weather data year is 2012)

Error: EPW PARSING ERROR.

[ Error Type ]: Date time mismatch for data period # Data (60 mins interval)
[Total Number]: 7344
-- Location --------------------------------------------------------------------
Line 1425: input - 2/29 01:XX, but expecting - 3/1 01:XX
Line 1426: input - 2/29 02:XX, but expecting - 3/1 02:XX
Line 1427: input - 2/29 03:XX, but expecting - 3/1 03:XX
Line 1428: input - 2/29 04:XX, but expecting - 3/1 04:XX
Line 1429: input - 2/29 05:XX, but expecting - 3/1 05:XX
Line 1430: input - 2/29 06:XX, but expecting - 3/1 06:XX
Line 1431: input - 2/29 07:XX, but expecting - 3/1 07:XX
Line 1432: input - 2/29 08:XX, but expecting - 3/1 08:XX
Line 1433: input - 2/29 09:XX, but expecting - 3/1 09:XX
Line 1434: input - 2/29 10:XX, but expecting - 3/1 10:XX
...[truncated. First 10 are shown.]

from eplusr.

Another problem after I update the package is that:

When I trying to all a new field in the schedule, it can not detect the character I list:

model$add(Schedule_Compact = list(name = "BLDG_EQUIP_SCH4", "Fraction" ,"Through: 1/15","For: Weekdays", "Until: 01:00" , "0.20"))

The error is:

Error: Failed to add object(s).

x [1] Errors found during validation.

-- [1] Invalid Character -------------------------------------------------------
Fields below should be characters but are not:

Class: <Schedule:Compact>
\- Object [ID:Input #1] <BLDG_EQUIP_SCH4>
   \- 6: "0.2";         !- Field 4

from eplusr.

the weather data year is 2012

Using real year data with leap day needs additional cautions in EnergyPlus. The leap year can only treated as correctly supported in EnergyPlus v9.1.0. There are lots of refactoring on WeatherManager in EnergyPlus after v8.9.0. Some behaviors have been changes. I would say special attention should be paid in order to correctly run a leap-year simulation with actual weather data before v9.1.0.

I did some tests on how EnergyPlus handle AMY data with leap year. See this gist. Below is the results:

#     version type_runperiod type_epw num_row num_leap
#  1:     8.8            tmy  nonleap    8760       24
#  2:     9.0            tmy  nonleap    8760       24
#  3:     9.1            tmy  nonleap    8760       24
#  4:     8.8            amy  nonleap    8760       24
#  5:     9.0            amy  nonleap    8760       24
#  6:     9.1            amy  nonleap    8760       24
#  7:     8.8            tmy     leap    8784       48
#  8:     9.0            tmy     leap    8784       48
#  9:     9.1            tmy     leap    8760       24
# 10:     8.8            amy     leap    8784       48
# 11:     9.0            amy     leap    8784       48
# 12:     9.1            amy     leap    8784       48

In summary:

1. If your input weather has a leap year, even if no Start Year is given in RunPeriod in your IDF, you will still get 366 days in v8.9 and v9.0. It means that the weather file can overwrite RunPeriod settings. This issues has been fixed via #7199. In EnergyPlus v9.1, Feb 29 gets skipped during simulation.
2. If your input weather does not have a leap year but a Start Year is given in RunPeriod in your IDF, simulation can complete successfully, without any warnings on the missing Feb 29 data in your weather. There is an open issue about this in EnergPlus GitHub Repo.

So in order to simulate an AMY weather data with leap year:

1. Set a Start Year (in EnergyPlus <= v8.9) or Begin Year (in EnergyPlus v9.0 or later) in your RunPeriod object as 2012.
2. Create your own weather file with 2012 weather data.
3. Make sure the leap year flag in the HOLIDAY/DAYLIGHT SAVING header in EPW file is set to yes. Note that all weather files in EnergyPlus website have been set leap year indicator to no by default. When creating your own weather file, you have to manually change it to yes.

In v0.10.0, eplusr tries to automatically check any inconsistencies between the headers and the core data, in order to avoid any possible issue. I guess leap year flag is not changed when you created your weather file. With the leap year flag being no and Feb 29 data presenting in your weather, read_epw() gives the error you showed in this issue.

Unfortunately, I didn’t know how EnergyPlus parse and process EPW file during simulation when I created $set_data() method in Epw class in v0.9.X. If you create your weather file using that method, you probably will have to manually set the leap year indicator to yes by changing the first word on the 5th line of your EPW file. Normally the 5th line will look like No,0,0,0. Just change No to Yes and save your file.

There is also a bug in v0.10.0 that using $set() in Epw class did not update the leap year flag in the header file. This has been fixed via b117015

model$add(Schedule_Compact = list(name = "BLDG_EQUIP_SCH4", "Fraction" ,"Through: 1/15","For: Weekdays", "Until: 01:00" , "0.20"))

This is also a bug which has been fixed via 53e2830. Should work OK in the development version.

from eplusr.

By the way, you can install the development version of eplusr by doing:

remotes::install_github("hongyuanjia/eplusr")

from eplusr.

Now eplusr v0.10.1 has already landed on CRAN. You can install it directly using install.packages("eplsur").

from eplusr.