Hi all!

I was thinking it'd be great if you could toggle whether or not to set the RNG's random seed. You would want to set it once per analysis as far as I can tell. I see two scenarios where you'd want to think about whether or not you'd want to set random seed--

1. You want to explore how much your GA's randomness impacts the variability in your curves and thereby energy use. In this case you would not want to set the random seed as you'd want to see the range of your "solution space." How much can my curves vary for identical inputs and how much does this affect my results?

2. You have confidence in your output variability and now want to ensure consistent results. For example, let's say after your variability study you find that cooling energy can vary by 0.5-1% and you decide that's good enough. But you wouldn't want a user to get different results every time, even if it varies slightly. You would want to set the seed here.

Move all equipment references out of the non-equipment classes. For instance all mentions of chiller specific attributes in curves.py.

Add the capabilities to calculate the IPLV based on either AHRI Standard 550/590 or 551/591.

This will likely require a new attribute for chillers.

To Do Task: Add error test cases for DX system operation.

• compressor_speed is not assigned, see here
• there's not units for the capacity, users might want to specify the capacity using different units, just like for chillers

Add basic assumptions like 'efficiency' means 'net efficiency' not 'gross efficiency' in the doc file.

This issue is linked to the JOSS Review: openjournals/joss-reviews#4876.

In the QuickStart Guide Section of the documentation, the json example (in the command line section) is malformed:

{
    "Quickstart_Guide_Chiller": {
    "eqp_type": "chiller",
    "compressor_type": "screw",
    "condenser_type": "water",
    "compressor_speed": "constant",
    "ref_cap": 300,
    "ref_cap_unit": "ton",
    "full_eff": 0.61,
    "full_eff_unit": "kw/ton",
    "part_eff": 0.52,
    "part_eff_unit": "kw/ton",
    "sim_engine": "energyplus",
    "model": "ect_lwt",
    "do": {
        "generate_set_of_curves": {
        "vars": ["eir-f-plr"],
        "method": "nearest_neighbor",
        "tol": 0.005,
        "export_path": "./",
        "export_format": "idf",
        "export_name": "Quickstart_Guide_Chiller"
        }
    }
}<<< missing a {

In the example detailed in https://pnnl.github.io/copper/Additional%20Examples.html#repeatability, a random seed is specified, but random_seed is not a parameter of the cp.chiller class.

full_eff_target = 1.188
full_eff_target_alt = 1.178
part_eff_target = 0.876
part_eff_target_alt = 0.869

chlr = cp.chiller(
    compressor_type="scroll",
    condenser_type="water",
    compressor_speed="constant",
    ref_cap=100,
    ref_cap_unit="ton",
    full_eff=full_eff_target,
    full_eff_unit="kw/ton",
    full_eff_alt=full_eff_target_alt,
    full_eff_unit_alt="kw/ton",
    part_eff=part_eff_target,
    part_eff_unit="kw/ton",
    part_eff_ref_std="ahri_550/590",
    part_eff_alt=part_eff_target_alt,
    part_eff_unit_alt="kw/ton",
    part_eff_ref_std_alt="ahri_551/591",
    model="ect_lwt",
    sim_engine="energyplus",
    random_seed=1 <<< TypeError: __init__() got an unexpected keyword argument 'random_seed'
)

Many of the example code-blocks don't show the import copper as cp. The first code block at the top of each page should at least contain the import statement.

• PLR is passed as an argument to the function used to calculate the LCT, however, PLR depends on the LCT
• The evaporator flow rate is used in place of the condenser flow rate to calculate the LCT
• The ECT and LWT temperatures are a mix of both AHRI 550/590 and AHRI 551/591.

Hi all,

When doing testing on TSPR's copper implementation I hit a bug with copper that I couldn't resolve. Running either the "nearest_neighbor" or "weighted_average" method match gave me an error that said the following:

AttributeError: 'float' object has no attribute 'sqrt'

File "/home/gonz102/.local/lib/python3.8/site-packages/copper/curves.py", line 368, in l2_norm
Y = np.matmul(np.sqrt((data - ref_data) ** 2), weights)
TypeError: loop of ufunc does not support argument 0 of type float which has no callable sqrt method

I could not resolve why this was. Below is a snippet of one of the JSONs. The rest are saved as text files below (git didn't like the JSON file extension).

{
  "chiller_plant_loops-6988": {
    "eqp_type": "chiller",
    "compressor_type": "centrifugal",
    "condenser_type": "water",
    "compressor_speed": "any",
    "ref_cap": 250.0,
    "ref_cap_unit": "ton",
    "full_eff": 5.8,
    "full_eff_unit": "cop",
    "part_eff": 6.4,
    "part_eff_unit": "cop",
    "sim_engine": "energyplus",
    "model": "ect_lwt",
    "do": {
      "generate_set_of_curves": {
        "vars": [
          "eir-f-plr"
        ],
        "method": "nearest_neighbor",
        "tol": 0.005,
        "random_seed": 10,
        "export_path": "./",
        "export_format": "json",
        "export_name": "chiller_plant_loops-6988"
      }
    }
  }
}

air_cooled_const_speed_code_efficiency.txt
water_cooled_centrifugal_code_efficiency.txt
water_cooled_pos_displ_code_efficiency.txt

When using the best_match lookup approach, it's possible that not all curves retrieved are normalized to 1.0, and when running the optimization on a single variable the target efficiency might not be met because the curve that is being modified will be normalized. An error should be raised when a user tries to generate such case.

As per a discussion with @jugonzal07, Copper should provide some degree of user-input validation.

Examples:

• Do not attempt to run if the input reference capacity of a chiller is 0 or negative
• Do not attempt to run if the input targeted full load efficiency or part load efficiency of a chiller is 0 or negative

In chiller.py get_ref_cond_flow_rate function line 166~167
seems cap_f_lwt_lct_rated and cap_f_lwt_lct to be the same?

Move best_match base curve generation out of generature_set_of_curves()

Add a command line interface so copper can be seamlessly integrated into other tools and workflows.

Hi all,

I noticed a few things were missing in the 0.21 schema that were previously available. Those enumerations and fields were:

Under chiller:

Under generate curves, the max_restart key is missing.

Add unit tests for #34

Currently, the aggregation of curves is not integrated in the process of generating the curves. It probably make sense to integrated it so we could then do it behind the scene so users would not have to do it manually. Here's a an example of what inputs would look like after implementation:

import copper as cp

chlr = cp.chiller(ref_cap=300, ref_cap_unit="ton",
                  full_eff=0.650, full_eff_unit="kw/ton",
                  part_eff=0.48, part_eff_unit="kw/ton",
                  sim_engine="energyplus",
                  model="lct_lwt",
                  compressor_type="screw", 
                  condenser_type="water",
                  compressor_speed="constant")

chlr.generate_set_of_curves(vars=['eir-f-plr'], method="NN-weighted-average")

According to PEP8, "Class names should normally use the CapWords convention.". This would prevent awkward references such as copper.chiller.chiller

Not a big deal, but worth mentioning...

Split the fitness function and apply a linear scaling for each fitness sub-function.

The code-base uses print-statements to inform the user. Depending on the application, this is not wanted:

Make your code publish-ready
Let’s prepare your code for the uploading. First, you should remove all “print” statements from your code. It’s annoying when you work with a library and your command prompt is flooded with print messages that are not yours — therefore remove all of them. If you want to inform the user about certain activities, use logging.

https://medium.com/@joel.barmettler/how-to-upload-your-python-package-to-pypi-65edc5fe9c56

Also, users would know what print statement is an error / info / debug -statement.

Copper uses mostly SI units for its calculations but performance curves could be used in other simulation tools that use IP units (DOE-2) hence a need for a translation process.

The database currently doesn't include at least a curve for each combination of compressor speed control, compressor type, condenser type so it's possible that an aggregated curve cannot be created. When this case arise, we should be able to provide an error message.

copper run in.json generates the following error:

  File "C:\Python310\lib\site-packages\copper\cli.py", line 39, in run
    obj = eval(eqp_props["eqp_type"])(**obj_args)
TypeError: 'module' object is not callable

This was not the case in 0.1.5

Reminder of issue encountered while working on the change code proposal with the wrong efficiency used in the live version of 90.1.

Address existing issues in the calc_eff_ect function for DX_system;
Discuss if other function is needed for DX_system.

Hi @lymereJ, I guess we have a duplicate DX curve file here?
copper/data/unitary_dx_curves.json

I am new to copper and am trying to run the example from the quickstart guide. However, it never finishes. On looking, it seems to be getting stuck in the while loop in generators.run_ga, but I'm not sure why. I'd appreciate any suggestions.

Edit the calc_rated_eff function to improve its input/output processing capabilities. This development should focus on streamlining data handling and ensuring compatibility with various data formats.

Add unit tests for #46.

Hi all,

I found myself a bit stumped debugging upgrading to a new version of copper in a new environment only to find that I was taking this message too literally.

While I was able to piece together it was due to not having a valid schema, I thought the error was reporting that my JSON file was in the wrong place. Perhaps different error messages for finding the file and another for schema validation would be more clear!

Can the first two references have an author (Main author or organization)? instead, the whole title is referenced as the author, which makes it hard to read.

Remove typical method, associated code and data.

This is redundant:

This issue is linked to the JOSS Review: openjournals/joss-reviews#4876.

Following the QuickStart Guide running on Windows, the command copper run in.json produces one file: .idf. It does not generate the curves information (json) as described in the documentation:

# Taken from https://pnnl.github.io/copper/Quickstart%20Guide.html#using-copper-s-command-line-interface
{
    "Quickstart_Guide_Chiller": {
        "eir-f-t": {
        "type": "bi_quad",
        "ref_evap_fluid_flow": null,
        "ref_cond_fluid_flow": null,
        "ref_lwt": 6.67,
        "ref_ect": 29.4,
        "ref_lct": null,
        "units": "si",
        "x_min": 5.0,
        "y_min": 24.0,
        "x_max": 10.0,
        "y_max": 35.0,
        "out_min": 0.0,
        "out_max": null,
        "coeff1": 0.933884,
        "coeff2": -0.058212,
        "coeff3": 0.00450036,
        "coeff4": 0.00243,
        "coeff5": 0.000486,
        "coeff6": -0.001215,
        "coeff7": 0.0,
        "coeff8": 0.0,
        "coeff9": 0.0,
        "coeff10": 0.0
        },
        "cap-f-t": {
        "type": "bi_quad",
        "ref_evap_fluid_flow": null,
        "ref_cond_fluid_flow": null,
        "ref_lwt": 6.67,
        "ref_ect": 29.4,
        "ref_lct": null,
        "units": "si",
        "x_min": 5.0,
        "y_min": 24.0,
        "x_max": 10.0,
        "y_max": 35.0,
        "out_min": 0.0,
        "out_max": null,
        "coeff1": 0.257896,
        "coeff2": 0.0389016,
        "coeff3": -0.00021708,
        "coeff4": 0.0468684,
        "coeff5": -0.00094284,
        "coeff6": -0.00034344,
        "coeff7": 0.0,
        "coeff8": 0.0,
        "coeff9": 0.0,
        "coeff10": 0.0
        },
        "eir-f-plr": {
        "type": "quad",
        "ref_evap_fluid_flow": null,
        "ref_cond_fluid_flow": null,
        "ref_lwt": 6.67,
        "ref_ect": 29.4,
        "ref_lct": null,
        "units": "si",
        "x_min": 0.0,
        "y_min": 0.0,
        "x_max": 1.0,
        "y_max": 1.0,
        "out_min": 0.0,
        "out_max": null,
        "coeff1": 0.222903,
        "coeff2": 0.313387,
        "coeff3": 0.46371,
        "coeff4": 0.0,
        "coeff5": 0.0,
        "coeff6": 0.0,
        "coeff7": 0.0,
        "coeff8": 0.0,
        "coeff9": 0.0,
        "coeff10": 0.0
        }
    }
}

The .idf file produced is:

Curve:Biquadratic,
   _eir-f-t,
   0.4714919803545788,
   -0.0003413558515812992,
   -0.0006979572001416824,
   0.02997434988897861,
   -0.0002825958540954729,
   -0.000386000186145715,
   -999,
   999,
   -999,
   999,
   0,
   999;

Curve:Quadratic,
   _eir-f-plr,
   0.2307348541782999,
   0.1814196166337366,
   0.5873280781879636,
   -999,
   999,
   -999,
   999,
   0,
   999;

Curve:Biquadratic,
   _cap-f-t,
   0.9685131980885846,
   -0.004964252905445725,
   0.0009250222553367597,
   0.0005571266682425913,
   -8.731725051830714e-05,
   0.000421644919398898,
   -999,
   999,
   -999,
   999,
   0,
   999;

Description:

This issue ticket outlines a series of enhancements and bug fixes required for the Unitary DX System module. The goal is to ensure robust functionality, accurate calculations, and comprehensive testing for this module. The following tasks are identified as critical next steps:

Tasks:

1. Complete unitary_dx_curves.json:

   • The unitary_dx_curves.json file is currently pending completion. Now, the class can be loaded correctly and 'get_ref_values()' works. This task involves finalizing the JSON structure and ensuring it contains all necessary data for the Unitary DX system.

2. Develop I/O Process in calc_rated_eff Function:

   • Enhance the calc_rated_eff function to improve its input/output processing capabilities. This development should focus on streamlining data handling and ensuring compatibility with various data formats.

3. Correct calc_eff_ect Function Based on a Given Model:

   • Address existing issues in the calc_eff_ect function. This task requires adjusting the function to align with a specified model, ensuring accuracy in efficiency calculations at different entering coil temperatures (ECT).

4. Resolve Bugs in get_ref_cond_flow_rate Function:

   • Pending bug fixes in the get_ref_cond_flow_rate function (originally identified in chiller.py) need to be addressed. This involves debugging and correcting the function to ensure it accurately retrieves reference condition flow rates.

5. Create and Implement Test Cases:

   • Develop comprehensive test cases for the Unitary DX system module. This includes creating scenarios that cover a wide range of use cases and conditions. Implement these tests to validate the functionality and reliability of the module.

Expected Outcomes:

• A fully functional and reliable Unitary DX system module in the software.
• Enhanced accuracy and efficiency in the system's performance calculations.
• A robust set of test cases ensuring the module's resilience against various scenarios and data inputs.