Kk2406/Ll huggingface dataset:
K562 Genome Browser SVG Export
Domain: life_sciences — Genomics & Sequence Analysis

Summary: Create an hg19 genome-browser SVG for a K562 regulatory locus using a structural-variant VCF and an H3K27ac BigWig signal track.

Task prompt:
You are a bioinformatics analyst working on a K562 regulatory genomics visualization task.

Task directory:
- `base`

Goal:
- Create a genome-browser SVG view for the hg19 TP53 locus: `chr17:7571651-7590910`.
- The view must include both the provided K562 structural variant VCF track and the K562 H3K27ac BigWig signal track at the same time.

Input files:
- Variant calls: `base/input/ENCFF960SSF.vcf.gz`
- H3K27ac signal: `base/input/wgEncodeBroadHistoneK562H3k27acStdSig.bigWig`
- Machine-readable task config: `base/input/task_config.json`

Available software:
- You may use the UCSC Genome Browser, IGV, WashU Epigenome Browser, or another browser/tool capable of loading VCF and BigWig tracks on hg19 and exporting SVG.
- A helper that opens the UCSC hg19 locus page is available with:
  `bash base/software/open_ucsc_browser.sh`

Output:
- Save exactly one SVG file to `base/output/output.svg`.
- The SVG must be valid XML with an `<svg>` root.
- The SVG should visibly show the hg19 locus labels, the VCF/variant track, and the K562 H3K27ac signal track.
- Do not save the final answer under any other filename.


Required actions:
Open the specified hg19 locus for the assigned variant.
Load or display the provided VCF and H3K27ac BigWig tracks together.
Export or create a valid SVG with locus labels, both tracks, and browser/build provenance.
Save the final artifact as output/output.svg and use no alternate filename.

Software: UCSC Genome Browser
Python

Input files:
name: ENCFF960SSF.vcf.gz
format: VCF.GZ
description: K562 structural variant calls to show as the variant track.
name: wgEncodeBroadHistoneK562H3k27acStdSig.bigWig
format: BigWig
description: K562 H3K27ac signal track for the target locus.
name: task_config.json
format: JSON
description: Variant-specific locus, genome build, output name, and track filenames.
Yeast Colony Detection
Domain: life_sciences — Cell & Imaging Biology

Summary: Detect red yeast colonies in a masked agar-plate image and export a colony count plus centroid measurement table.

Task prompt:
You are analyzing a yeast colony plate image on Linux.

## Your Task
Detect the red yeast colonies growing on the agar plate while excluding white dots and other visual noise.

## Visible Inputs
- Plate image: `base/input/6-1.jpg`
- Plate-region mask: `base/input/PlateTemplate.png`
- CellProfiler entry point, if provisioned: `base/software/cellprofiler`

## What You Must Do
1. Use the plate image and mask to identify red yeast colonies inside the plate region.
2. Create a reproducible detection workflow in CellProfiler 4.2.8 or another image-analysis workflow available on the VM.
3. Count the detected red colonies.
4. Save all required outputs under `base/output`.

## Required Outputs
- JSON count file: `base/output/answer.json`
  - exact schema: `{"colony_count": <integer>}`
- Measurement CSV: `base/output/measurements/RedColonies.csv`
  - include one row per detected red colony
  - include numeric centroid columns named `Location_Center_X` and `Location_Center_Y`
  - include `ObjectNumber` if your workflow can provide it

## Constraints
- Do not modify files under `base/input`.
- Only read the visible files under `base/input`.
- Keep all task-produced files inside `base/output`.


Required actions:
Use the plate image and mask to identify red yeast colonies inside the plate region.
Exclude white dots and unrelated visual noise from the colony detections.
Create a reproducible CellProfiler or image-analysis workflow on the Linux VM.
Write `answer.json` with an integer `colony_count`.
Write `measurements/RedColonies.csv` with one row per detected colony and numeric centroid columns.

Software: CellProfiler 4.2.8
Python
NumPy

Input files:
name: 6-1.jpg
format: JPEG
description: Yeast agar plate image.
name: PlateTemplate.png
format: PNG
description: Aligned plate-region mask.
ZDOCK HIV Dimer Interface Scoring
Domain: life_sciences — Biomolecular Structure & Design

Summary: Evaluate ten precomputed HIV protease dimer docking poses by computing fixed interface overlap, Fnat, IRMSD, and final ranking metrics.

Task prompt:
You are evaluating precomputed HIV protease dimer docking predictions on a Linux VM.

## Input Files
- Native complex: `base/input/1HVR.pdb`
- Chain A structure: `base/input/1HVR_chainA.pdb`
- Chain B structure: `base/input/1HVR_chainB.pdb`
- Docking-pose archive: `base/input/top_preds.tar.gz`

## Your Task
1. Use `base/input/1HVR.pdb` to derive native Chain A / Chain B interface residues.
   An interface residue is any residue with at least one atom within 5 Angstrom of any atom
   on the opposite chain.
2. Unpack `base/input/top_preds.tar.gz` to obtain `complex.1.pdb` through `complex.10.pdb`.
3. For each docking pose, identify predicted interface residues using the same 5 Angstrom
   atom-distance cutoff.
4. Compute these metrics for every pose:
   - `Overlap Score` = |Predicted interface residues intersect Native interface residues| /
     |Native interface residues|.
   - `Fnat` = fraction of native heavy-atom contacts recovered, where a contact is any pair
     of heavy atoms within 5 Angstrom.
   - `IRMSD` = RMSD in Angstrom after superposing the predicted structure onto the native
     structure using backbone C-alpha atoms of the native interface residues, then measuring
     RMSD over those same C-alpha atoms.
   - `Final Score` = 0.5 * Fnat + 0.3 * Overlap Score - 0.2 * (IRMSD / 10).
5. Rank all 10 poses by `Final Score`, higher is better.

## Required Output
Save exactly one CSV file at:

```text
base/output/zdock_interface_scores.csv
```

The CSV must contain exactly 10 rows, one for each ZDOCK pose rank 1 through 10, and these
columns with exact spelling:

- `Pose Rank (ZDOCK)`
- `Overlap Score`
- `Fnat`
- `IRMSD`
- `Final Score`
- `Final Rank`

Do not modify files under `base/input`. Keep all generated files inside
`base/output`.


Required actions:
Use `input/1HVR.pdb` to derive native Chain A / Chain B interface residues with a 5 Angstrom atom-distance cutoff.
Unpack `input/top_preds.tar.gz` and process `complex.1.pdb` through `complex.10.pdb`.
Compute overlap, Fnat, interface C-alpha IRMSD after superposition, and the final score for every pose.
Rank all ten poses by final score and write `output/zdock_interface_scores.csv`.

Software: Python
BioPython
NumPy

Input files:
name: 1HVR.pdb
format: pdb
description: Native Chain A / Chain B complex used to derive the native interface and contacts.
name: 1HVR_chainA.pdb
format: pdb
description: Submitted Chain A structure.
name: 1HVR_chainB.pdb
format: pdb
description: Submitted Chain B structure.
name: top_preds.tar.gz
format: tar.gz
description: Archive containing the ten docking pose PDB files.
Aerobics World Cup Trio Difficulty Scoring
Domain: other — Sports

Summary: Inspect the staged aerobics trio routine video and FIG rulebook, then produce the required chronological difficulty-element spreadsheet for the routine.

Task prompt:
You are working on Ubuntu.

## Your Task
Inspect the routine video and the FIG Aerobic Gymnastics Code of Points, then
produce a difficulty-element spreadsheet for the routine.

## Visible Inputs
- Video: `variant_1/input/trio.mov`
- Rulebook PDF: `variant_1/input/FIG Aerobic Gymnastics Code of Points (2025-2028).pdf`

## Output
Write exactly one spreadsheet to `variant_1/output/difficulty_element_log.xlsx`.

The spreadsheet must contain exactly these four columns:
- `element_name`
- `FIG_code`
- `credited_value`
- `meets_minimum_standard`

Use one row per detected difficulty element, in chronological order.
The total D-score implied by the `credited_value` column should fall between
`7.0` and `7.2`.


Required actions:
Open the staged routine video at `input/trio.mov`.
Read the staged FIG Code of Points PDF at `input/FIG Aerobic Gymnastics Code of Points (2025-2028).pdf`.
Identify each credited difficulty element in chronological order.
Write exactly one workbook to `output/difficulty_element_log.xlsx` with columns `element_name`, `FIG_code`, `credited_value`, and `meets_minimum_standard`.

Software: VLC
LibreOffice
Python
xdg-open

Input files:
name: trio.mov
format: video
description: Staged competition routine video for the men's trio performance
name: FIG Aerobic Gymnastics Code of Points (2025-2028).pdf
format: PDF
description: Agent-visible rulebook used to identify FIG codes and credited values
Game Port Reference Capture: Magic Tower
Domain: other — 3D, Animation & Interactive Media

Summary: Stand-in for the asset-capture step of a Flash-to-modern-engine port: drive the legacy Magic Tower (mota-24) build under Ruffle and collect per-floor reference screenshots that downstream engineers will use as ground-truth for tile layout, HUD placement, and level-script reconstruction.

Task prompt:
## Context

A small game studio plans to re-implement the legacy Flash dungeon-crawler **Magic Tower (mota-24)** on a modern stack. Before any port code is written, the porting workflow requires a clean set of **per-floor reference screenshots** captured from the original build — these screenshots become the visual contract that downstream engineers diff against while re-creating tile maps, HUD elements, and per-floor enemy/item placement.

Your role in that workflow is the reference-capture pass: drive the original game far enough to expose floors 1–3, and save one labeled screenshot per floor reached.

## Goal

Launch the original Flash build under Ruffle, advance through the early-game progression, and produce labeled per-floor reference screenshots up to and including floor 3.

## Steps

1. The game is auto-opened by the task setup at `mota_24_ez\input\mota-24.swf` in Ruffle. If the window is not already focused, focus it.
2. Wait for the title / loading screens to finish and enter the running game world.
3. Play forward through floors 1 → 3 using standard movement and interaction (no cheats, no save-state hacks). Combat / item pickups / stair-use are expected; this is what a porting engineer would do to surface each floor.
4. Each time you arrive on a new floor, capture a full-window screenshot of the rendered game and save it to `mota_24_ez\output\$FLOOR_NUMBER$.png`, where `$FLOOR_NUMBER$` is the integer floor index (`1.png`, `2.png`, `3.png`).

## Acceptance

- One PNG per floor reached, named by floor number, exists in the output directory.
- Each PNG must depict the correct floor (visually matches the original game's floor layout) — these will be diffed against held-out reference frames.

Required actions:
Focus the Ruffle window with mota-24.swf loaded (the task setup auto-launches it)
Wait for the title / loading screens and enter the actual game world
Play forward through floors 1 → 3 using normal movement and interaction (no cheats)
On arrival at each new floor, save a full-window screenshot as output/<floor>.png (1.png, 2.png, 3.png)

Software: Ruffle (Flash emulator)

Input files:
name: mota-24.swf
format: SWF
description: Flash game to play
ADAPT-VQE Molecular Ground-State Energy
Domain: physical_sciences — Quantum Computing

Summary: Use only NumPy and SciPy to solve three visible Jordan-Wigner molecular Hamiltonians with VQE / ADAPT-VQE style logic, then write a structured `results.json` with tier-wise energies and method metadata.

Task prompt:
You are solving a molecular ground-state energy benchmark using only NumPy and
SciPy. The visible inputs are a task statement and three Jordan-Wigner
Hamiltonians:

- `base/input/h2_hamiltonian.json`
- `base/input/lih_hamiltonian.json`
- `base/input/beh2_hamiltonian.json`

Read `base/input/problem_spec.md` first. It describes the VQE / ADAPT-VQE task,
the tier structure, the visible output schema, and the library constraints.

## Your Task
1. Set up the provided runtime environment:
   ```
   uv sync --frozen --project base/input/runtime_env
   ```
   Then use `base/input/runtime_env/.venv/bin/python` (or activate the venv).

2. Implement dense-matrix VQE / ADAPT-VQE logic using only NumPy and SciPy.
   You may use `scipy.linalg.expm` and `scipy.optimize.minimize`.

3. Use the visible Hamiltonian JSON files as the source of truth for:
   - molecule identity
   - qubit count
   - electron count
   - active-space note
   - Pauli-string Hamiltonian terms

4. Produce exactly one file under `base/output`:
   - `results.json`

5. `results.json` must follow the schema in `base/input/problem_spec.md` and
   include:
   - Tier 1 (`H2`): `molecule`, `energy_ha`, `method`, `n_parameters`
   - Tier 2 / 3: `molecule`, `energy_ha`, `method`, `adapt_iterations`,
     `n_parameters`, `operator_sequence`

## Constraints
- Allowed libraries: NumPy and SciPy only.
- Banned: Qiskit, Cirq, PennyLane, OpenFermion, tequila, or any other
  quantum-computing library.
- Write only under `base/output`.
- Do not modify anything under `base/input`.


Required actions:
Read the staged prompt and three visible Hamiltonian JSON files under `input/`.
Prepare the staged NumPy / SciPy runtime manifest under `input/runtime_env/`.
Implement VQE / ADAPT-VQE style logic without any quantum-computing libraries.
Write `output/results.json` with tier-wise `molecule`, `energy_ha`, and method metadata.

Software: Python
NumPy
SciPy

Input files:
name: Problem specification
format: Markdown
description: Sanitized visible task statement and output schema.
name: Tier Hamiltonians
format: JSON
description: Visible Jordan-Wigner Hamiltonians for H2, LiH, and BeH2.
name: Runtime manifest
format: uv project
description: Pinned NumPy / SciPy runtime manifest for the agent.
CMIP6 Climate Emulation Pipeline
Domain: physical_sciences — Earth & Atmospheric Sciences

Summary: Build an end-to-end climate-emulation pipeline from a staged CMIP6-derived Zarr store and predict the held-out SSP245 test window for temperature and precipitation fields.

Task prompt:
You are a climate scientist building an end-to-end climate-emulation pipeline on Linux.

## Your Task

Build a climate-emulation pipeline from a staged CMIP6-derived Zarr store and predict the held-out SSP245 test window.

1. Bootstrap the Python runtime: `bash <software_dir>/bootstrap_runtime.sh`
2. Open the staged Zarr store at `<input_dir>/data.zarr/` with cftime-aware decoding.
3. Build training tensors from scenarios `ssp126`, `ssp370`, and `ssp585` across all months.
4. Build test inputs from the last 120 months of `ssp245`.
5. Use `member_id = 0` for target tensors.
6. Broadcast scalar forcings (`CO2`, `CH4`) to the `(48, 72)` spatial grid.
7. Rename `latitude`/`longitude` dimensions to `y`/`x` for spatial inputs.
8. Fit normalization on the training split only.
9. Train any benchmark-safe open-source model or baseline.
10. Write the required output files under `<output_dir>/` exactly as described by `<input_dir>/output_contract.json`.

## Input Files

- Zarr store: `<input_dir>/data.zarr/`
- Metadata: `<input_dir>/metadata.json`
- Output contract: `<input_dir>/output_contract.json`
- Starter guide: `<input_dir>/Starter.md`
- Runtime manifest: `<input_dir>/runtime_env/`

## Runtime

- Bootstrap deps: `bash <software_dir>/bootstrap_runtime.sh`
- Run Python with deps: `<software_dir>/python_with_task_deps.sh your_script.py`

## Output

Save all required files under `<output_dir>/`:
- `processed/train_inputs.npy`, `processed/train_outputs.npy`, `processed/test_inputs.npy`
- `processed/metadata.json`, `processed/test_predictions.npy`
- `submissions/kaggle_submission.csv`

The visible `data.zarr` intentionally masks the held-out `ssp245` test-window target labels (`tas`, `pr`) as NaN. Use the training split to learn a predictor.

Required actions:
1. Bootstrap the staged Python runtime via `software/bootstrap_runtime.sh`
2. Open the masked CMIP6-derived `data.zarr` with cftime-aware decoding
3. Build training tensors from `ssp126`, `ssp370`, `ssp585` and test inputs from last 120 months of `ssp245`
4. Use `member_id = 0` for targets; broadcast scalar forcings; normalize dimension names
5. Fit normalization on training split only and train a climate-emulation model
6. Produce predictions for the held-out SSP245 test window
7. Serialize outputs: `.npy` arrays, `metadata.json`, and Kaggle-style CSV

Software: Python
xarray
numpy
pandas
PyTorch

Input files:
name: data.zarr
format: zarr
description: Benchmark-safe CMIP6-derived Zarr store with held-out SSP245 test-window targets masked to NaN
name: metadata.json
format: json
description: Dataset shapes, coordinates, and normalization summary
name: output_contract.json
format: json
description: Specifies required output file names, shapes, and formats
name: Starter.md
format: markdown
description: Step-by-step starter guide for the pipeline
Egt710 Table1 SMILES Extraction
Domain: physical_sciences — Chemistry & Materials Computation

Summary: Extract Table 1 from the staged paper, reconstruct the nine compounds, and deliver a CSV with validated SMILES and reported assay values.

Task prompt:
You are a medicinal chemistry researcher extracting a structure-activity table.

## Your Task
Use the uploaded paper PDF to reconstruct the nine compounds in **Table 1** and produce a CSV with validated SMILES strings.

## Input Files
- Paper PDF: `table1\input\source_paper.pdf`

## Software
- Launch the mandated SMILES validator from: `table1\software\ChemInfo.lnk`
- The shortcut opens the ChemInfo SMILES Generator & Checker:
  `https://www.cheminfo.org/flavor/malaria/Utilities/SMILES_generator___checker/index.html`

## What You Must Do
1. Open `table1\input\source_paper.pdf`
2. Locate Table 1 in the paper titled:
   `Discovery of EGT710, an Oral Nonpeptidomimetic Reversible Covalent SARS-CoV-2 Main Protease Inhibitor`
3. Extract compounds `1` through `9`
4. Reconstruct and validate each compound's SMILES string using ChemInfo
5. Save a CSV exactly to:
   `table1\output\submission.csv`

## Output Requirements
- The file must be CSV
- The columns must be exactly:
  `Compound_ID,SMILES,IC50_uM,Solubility_mM`
- Include exactly one row each for compound IDs `1,2,3,4,5,6,7,8,9`
- Do not save extra files

## Evaluation
- Rows are matched by `Compound_ID`
- `SMILES` is checked by chemical identity, not raw string equality
- `IC50_uM` and `Solubility_mM` must match the reference values
- Final score = fraction of correctly matched rows out of 9

Required actions:
Open the manuscript PDF from `input/source_paper.pdf`.
Locate Table 1 in the EGT710 paper and inspect compounds `1` through `9`.
Reconstruct each full molecule and validate the structure with the staged ChemInfo launcher.
Save one CSV exactly to `output/submission.csv`.

Software: Chrome

Input files:
name: Source paper
format: `.pdf`
description: Full paper containing Table 1 and the compound drawings
Exact Diagonalization of the J1-J2 Heisenberg Model
Domain: physical_sciences — Physics

Summary: Implement an exact-diagonalization workflow for a frustrated 4x4 spin-1/2 J1-J2 Heisenberg antiferromagnet and produce ground-state, correlation, and dynamical-structure-factor outputs.

Task prompt:
You are working on a Linux VM.

## Your Task
Implement an exact diagonalization workflow for the spin-1/2 `J1-J2` Heisenberg antiferromagnet on a `4x4` periodic square lattice in the conserved `S_z = 0` sector.

## Visible Input
- Problem specification: `base/input/problem_spec.md`

## Runtime
- Use the benchmark-provided `software/python` entry point at `base/software/python`.
- That entry point resolves to the VM's preinstalled `/usr/bin/python3.10` with NumPy and SciPy available.
- Do not install extra packages or use external quantum frameworks.

## What You Must Produce
Write the required files under `base/output`:
- `ground_state.npz`
- `correlations.npz`
- `dynamical_sf.npz`
- `results.json`

## Important Constraints
- Follow the file schema and scientific checks in `base/input/problem_spec.md`.
- Do not modify files under `base/input`.
- Do not write outside `base/output`.


Required actions:
Read the staged scientific specification in `input/problem_spec.md`.
Compute Tier 1 energies, spin gap, and a normalized ground-state vector in the `S_z = 0` sector.
Compute the full 16x16 spin-spin correlation matrix and static structure factor.
Compute the dynamical structure factor on 16 q-points and 500 omega points with Lanczos reproducibility coefficients.
Write `ground_state.npz`, `correlations.npz`, `dynamical_sf.npz`, and `results.json` under `output/` only.

Software: Python 3.10
NumPy
SciPy

Input files:
name: Problem specification
format: Markdown
description: Visible task statement, output contract, and scientific constraints for the 4x4 J1-J2 exact-diagonalization benchmark.
GLM Lake Calibration
Domain: physical_sciences — Environmental Modeling, Engineering & Water Resources

Summary: Calibrate a staged GLM 3 Lake Mendota model by editing one namelist file so the simulated vertical temperature profiles match the staged field observations.

Task prompt:
You are calibrating GLM (General Lake Model) 3 for Lake Mendota, Wisconsin.

## Your Task
Tune the staged GLM namelist so the simulated vertical water-temperature
profiles match the staged observations with RMSE below 1.5 C.

## Visible Inputs
- GLM namelist to edit: `base/input/glm3.nml`
- Observation file: `base/input/field_temp_oxy.csv`
- Forcing directory: `base/input/bcs`
- Runtime wrapper: `base/software/run_glm_from_input.sh`

## Software
- Use the staged GLM runtime wrapper at `base/software/run_glm_from_input.sh`
- The wrapper uses the benchmark-provided GLM 3 binary and shared libraries in
  `base/software`
- Do not assume `/usr/local/bin/glm` exists on this VM

## What You Must Do
1. Modify only `base/input/glm3.nml`.
2. Leave the observation CSV, forcing CSVs, and staged GLM runtime unchanged.
3. Run `base/software/run_glm_from_input.sh` to generate the simulation output.
4. Save the final simulation NetCDF exactly to `base/output/output.nc`.

## Important Constraints
- Only edit `base/input/glm3.nml` and write under `base/output`
- Do not replace the staged GLM binary
- The output must cover the required 2009-01-01 through late-2015 simulation window

Required actions:
Work in the staged Linux benchmark tree under `/media/user/data/agenthle/physical_sciences/glm_lake_calibration/base/`.
Modify only `input/glm3.nml`.
Run the staged entrypoint `software/run_glm_from_input.sh`, which exposes the bundled GLM binary and libraries.
Produce `output/output.nc` covering the required 2009-01-01 through at least 2015-12-29.
Achieve overall RMSE `< 1.5 C` against `input/field_temp_oxy.csv`.
`software/run_glm_from_input.sh`
`software/glm`
`software/bin/glm.bin`
`software/lib/`

Software: Python

Input files:
name: glm3.nml
format: GLM namelist
description: Only benchmark file the agent may modify; it contains the GLM parameter settings the agent must tune
name: field_temp_oxy.csv
format: CSV
description: Lake Mendota observation table with columns datetime, depth, temp, and OXY_oxy; the scorer compares simulated temperatures against the observed temp profiles
name: bcs/
format: CSV directory
description: Boundary-condition inputs used by GLM: meteo.csv, outflow.csv, pheasant.csv, and yahara.csv