semvec/pypi-packages huggingface dataset:
copper-bem 0.2.9
Performance curve generator for building energy simulation
Requires Python: <4.0,>=3.10

# Copper
Copper is a building energy simulation performance curve generator for heating, ventilation, and air-conditioning equipment. It uses a genetic algorithm to modify existing or a set of aggregated existing performance curves to match specific design characteristics including full and part load energy performance metric values.

Copper generates performance curves that can be used in most common building energy software such as [EnergyPlus](https://energyplus.net/) or [DOE-2](https://doe2.com/).

![Tests](https://github.com/lymereJ/copper/actions/workflows/tests.yml/badge.svg)
[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.7644215.svg)](https://doi.org/10.5281/zenodo.7644215)
[![status](https://joss.theoj.org/papers/9509076e1ef0a0c05f141fde6810c313/status.svg)](https://joss.theoj.org/papers/9509076e1ef0a0c05f141fde6810c313)

# Purpose
Results from building energy simulations largely depend on how heating and cooling equipment are modeled. As they rarely operate at their full load and rated performance it is important that reasonable data is used to model an heating or cooling equipment's part load performance. Copper was created to allow building energy modelers, engineers, and researchers to generate simulation-ready performance curves of heating and cooling equipment that not only capture their typical behavior at part load but are also generated to match a set of design characteristics such as full load and part load efficiencies.

While chillers, which are rated at both full load and part load through an integrated part load value (IPLV), are currently the main application of Copper, other heating and cooling equipment will be handled in the near future.

# Web Application
https://copper.pnnl.gov/

# Documentation
The documentation for Copper is hosted [here](https://pnnl.github.io/copper/index.html), it includes installation instructions, quick tutorials, examples, API documentation, and more.

# Contributing
Contributions (issues and pull requests) are welcomed and greatly appreciated. Guidelines are provided in the documentation.

# Help
If you need help using Copper, please open an issue and one of the developers will get back to you at their earliest convenience.
check-config 0.9.12
Check configuration files.
Requires Python: >=3.10
Keywords: automation, configuration



# Effortless Configuration Management with check-config


**Keep your development environment consistent, shareable, and version-controlled**

check-config is a fast, lightweight, declarative configuration management tool that ensures your configuration files
contain exactly what they should. Instead of managing entire config files,
you declare specific parts that must be present - making configurations shareable, maintainable, and verifiable.

## How It Works

Define your configuration requirements in simple TOML files, then let check-config ensure they're applied:

```toml
# Set your preferred editor
[[lines_present]]
file = "~/.bashrc"
lines = "export EDITOR=hx"
```

```toml
# Ensure git signing is configured
[[lines_present]]
file = "~/.gitconfig"
lines = """
[gpg]
        format = ssh
[commit]
        gpgsign = true
"""
```

Run `check-config --fix` to apply changes, or `check-config` to verify everything is in sync.

## Why check-config?

### 🔧 **Shareable Configuration Snippets**

Traditional dotfile repositories force users to adopt entire configuration files. check-config lets you share just the essential parts:
- Share your preferred Python formatting rules without forcing your entire `pyproject.toml`
- Distribute security settings without overwriting personal aliases
- Collaborate on team standards while preserving individual preferences

### ✅ **Enforce Team Standards**

Ensure consistent development environments across your team:

```shell
# In CI: Verify configurations are up-to-date
check-config

# For developers: Apply required configurations  
check-config --fix
```

Perfect for ensuring tools like Ruff, Black, and ESLint use consistent settings across all developers and CI pipelines.

### 📦 **Composable Configuration**

Combine multiple configuration files to build your complete setup:
- Base configurations for your team
- Personal tweaks and preferences  
- Project-specific requirements
- Environment-specific overrides

## Beyond Simple Lines

check-config supports multiple checker types for different configuration needs:
- **Lines present/absent**: Shell configs, text files
- **Key-value pairs**: TOML, JSON, YAML files
- **File existence**: Ensure critical files exist
- **And more**: See [docs/checkers.md](docs/checkers.md) for all features

## Get Started

Make a `check-config.toml` according your needs:

```toml
# Set your preferred editor
[[lines_present]]
file = "~/.bashrc"
lines = "export EDITOR=hx"
```

And use it:

```shell
# Check if configurations match requirements
check-config

# Apply missing configurations
check-config --fix
```

## Documentation

📖 **[Full Documentation](https://check-config.readthedocs.io)** - Complete guides, examples, and API reference

---

*Declare what you need. Share what matters. Keep everything in sync.*
cdef-pil-070126-0006 0.1.0
Parental income loss analysis pipeline.
Requires Python: >=3.9

# Parental Income Loss

## Stacked Event-Study Outputs
The stacked example writes results to:
- `output/stacked_event_study/stacked_results.csv`
- `output/stacked_event_study/stacked_results.parquet`

Each row contains:
- `sample`, `chapter`, `component` (event_time or horizon_*),
- `reference_year`, `target_year`, `event_time`,
- `att`, `se`, `conf_low`, `conf_high`,
- `n_pairs`, `n_treated`, `n_control`, `convergence`,
- `bucket_periods`, `horizon_start`, `horizon_end`, `horizon_label`, `bucket_weight`.

Bucket weighting defaults to treated-weighted (`n_treated`). Override with:
- `STACKED_BUCKET_WEIGHT=pairs`

## Quickstart: Custom Components
- Implement one or more of: `PopulationAssembler`, `CohortSelector`, `ExposureDetector`, `MatchingEngine`.
- Wire them into the pipeline with `CohortWorkflow::with_components`.
- Use `docs/component_contracts.md` to ensure required columns are present.

Example wiring:
```rust
let workflow = CohortWorkflow::with_components(builder, selector, matcher);
let outputs = workflow.run(sources, &detector, &registries, &plan, None)?;
```

## Stacked Event Study CLI
- Run the standalone stacked event-study on a parquet file:
  `cargo run -- --stacked-input path/to/stacked_inputs.parquet --did-outcome perindkialt13`
- Optional flags: `--stacked-samples`, `--stacked-chapter-col`, `--stacked-icd-col`,
  `--stacked-output-dir`, plus the existing `--stacked-*` config flags.

## Docs
- Component contracts: `docs/component_contracts.md`
- Custom component example: `crates/pil/examples/custom_components.rs`
- Custom selector example: `crates/pil/examples/custom_selector.rs`
- Custom matcher example: `crates/pil/examples/custom_matcher.rs`
- Custom detector example: `crates/pil/examples/custom_detector.rs`