config.yaml

simulation:
  dataset_name: "constellation_dataset_qwen2_7b_v2"
  num_scenarios: 25
  sat_k: 5
  sat_group_name: "weather"
  gs_k: 2
  tasks_k: 15 
  seed: 2026
  ollama_model: "qwen2:7b"
  ollama_temperature: 0.4
  semantic_enabled: true

payload:
  sensors_pool:
    - VIS
    - SAR
    - TIR
    - VNIR
    - NIR
  sensor_weights: [0.3, 0.25, 0.15, 0.15, 0.15]

  sensor_generation_rates:
    SAR: 80.0
    VIS: 40.0
    VNIR: 35.0
    NIR: 20.0
    TIR: 12.0

  sensor_constraints:
    SAR:
      max_look_angle_deg: 40.0
    VIS:
      max_look_angle_deg: 30.0
    VNIR:
      max_look_angle_deg: 30.0
    NIR:
      max_look_angle_deg: 30.0
    TIR:
      max_look_angle_deg: 35.0

  storage_capacity_pool_mb:
    - 32000.0   
    - 128000.0  
    - 512000.0  
    - 1024000.0 

  storage_capacity_weights: [0.4, 0.2, 0.2, 0.1]

  bands_config:
    X:
      weight: 0.6
      min_elevation_deg: 8.0
      max_slant_range_km: 2200.0
      downlink_rate_mb_s: 45.0
    S:
      weight: 0.2
      min_elevation_deg: 5.0
      max_slant_range_km: 2600.0
      downlink_rate_mb_s: 2.0
    Ka:
      weight: 0.2
      min_elevation_deg: 12.0
      max_slant_range_km: 1800.0
      downlink_rate_mb_s: 150.0

  min_sensors_per_sat: 2
  max_sensors_per_sat: 3

task_generation:
  polygon_ratio: 0.6
  min_area_deg: 0.05
  max_area_deg: 0.20
  min_duration: 5
  max_duration: 30
  min_release_delay: 0
  max_release_delay: 600
  min_lifetime: 18000
  max_lifetime: 345600
  priority_weights: [0.5, 0.3, 0.2]
  bounding_boxes:
    - name: "colombia_andina"
      lat_envelope: [2.0, 8.0]
      lon_envelope: [-77.0, -72.0]
    - name: "italia_centro_norte"
      lat_envelope: [40.5, 46.5]
      lon_envelope: [7.5, 14.5]
    - name: "indonesia_ecuatorial"
      lat_envelope: [-3.0, 3.0]
      lon_envelope: [100.0, 120.0]
  prompt_generation:
    sensor_categories:
      TIR: "thermal mapping heat signature surface temperature profile thermal anomaly detection"
      VNIR: "multispectral vegetation analysis chlorophyll absorption level NDVI index"
      SAR: "active radar scan microwave surface imaging cloud-penetrating capture"
      NIR: "near-infrared reflection water body boundary mapping soil moisture assessment"
      VIS: "high-resolution optical snapshot daylight photography RGB true-color imagery"
    system_instruction_template: |
      Return ONLY one block delimited by triple backticks with the language tag `prompt`.

      You are an Earth-observation mission operator submitting a task request to an automated satellite constellation planner.
      Your objective is to translate the raw physical simulation metadata provided in JSON format below into a single, highly realistic, and conversational English request.

      To maximize the naturalness and validation accuracy of the dataset, interpret the metadata organically according to these operational guidelines:

      1. GEOGRAPHIC CONTEXT (Interpret keys 'region_name' and nested 'location_details'):
         - Do NOT use raw technical system tags, underscores, or coordinate arrays in your final output.
         - Combine the JSON parameters naturally. Describe the location using a realistic combination of the 'country', 'city', and 'landmark' fields from 'location_details'.
         - If country, city, or landmark are "N/A", ignore them gracefully and describe the location using the remaining valid fields or the clean 'region_name'.

      2. MISSION ALLOCATION PRIORITY (Interpret key 'priority_level'):
         - Do NOT mention raw priority numbers or technical priority levels.
         - Priority indicates mission allocation authority and asset contractual value, NOT how close the deadline is. You must integrate specific operational phrases to reflect this structural hierarchy:
           * Priority 3 (High Importance): Use an authoritative, explicit, and commanding tone. Frame this as an "absolute institutional priority" or a "binding contract requirement" involving a "critical payload capture" or "mandatory directive". The language must heavily imply an "urgent operational execution" and an "un-preemptable mission lock".
           * Priority 2 (Medium Importance): Use a professional, direct, and standard operational tone. Describe this request as a "standard operational tasking", "commercial tasking", or "routine monitoring" part of a "baseline pipeline tracking" setup with "fixed parameters" representing "normal operational status" or a standard "workflow update".
           * Priority 1 (Low Importance): Use a casual, highly flexible, or opportunistic tone. Explicitly frame this as a "low priority importance" request with a "flexible schedule" for "opportunistic capture". Label it as a "non-essential background filler task" where the operator explicitly notes to "drop or reschedule at convenience", treating it as a "background survey" or "testbed tracking task".

      3. SENSORS AND PHYSICAL OBJECTIVES (Interpret key 'primary_sensor'):
         - Do NOT output technical abbreviations or acronyms (e.g., do NOT write VIS, SAR, TIR, VNIR, NIR).
         - Naturally weave the following operational objectives and descriptors into your request to explain the physical phenomenon to be observed:
           * VIS -> Explain the goal as a "high-resolution optical snapshot" for "daylight photography", "clear optical imagery", or "true-color visual documentation".
           * SAR -> Explain the goal as an "active radar scan" using "microwave surface imaging" for "cloud-penetrating capture", piercing heavy weather or capturing ground geometry.
           * TIR -> Explain the goal as "thermal mapping" to capture a "heat signature", "surface temperature profile", or for "thermal anomaly detection" and mapping heat emissions.
           * VNIR -> Explain the goal as "multispectral vegetation analysis" to assess "chlorophyll absorption level" or calculate a vegetation "NDVI index" and surface reflectance.
           * NIR -> Explain the goal as "near-infrared reflection" for "water body boundary mapping" or "soil moisture assessment" to discriminate gradients.

      4. RELATIVE TIMEFRAMES (Interpret keys 'target_day' and 'target_diurnal_period'):
              - Do NOT output raw UTC timestamps, digits, or countdown metrics.
              - CRITICAL CONTEXT: The temporal parameters represent a strict operational DEADLINE to deliver the data products to the user, NOT the orbital capture window. Your text must reflect this urgency naturally.
              - You are strictly forbidden from altering or extending this deadline. You must weave 'target_day' and 'target_diurnal_period' into a fluid conversational phrase that explicitly marks the upper limit for data availability using phrases like:
                * "...needed by [target_day] [target_diurnal_period] at the latest."
                * "...with a strict delivery deadline set for [target_day] [target_diurnal_period]."
                * "...ensuring the products are ingested into the pipeline before [target_day] [target_diurnal_period]."
              
              Operational vocabulary alignment:
              - If 'target_diurnal_period' is "overnight" -> The data must be ready by tomorrow's overnight/nighttime block. Do NOT write "afternoon" or "morning" as it would violate the deadline constraint.  
      
      Target task context JSON:
      {tasks_dataset}

      Now output ONLY the final natural user request inside:
      ```prompt
      ...your text here...
      ```

paths:
  gs_file_path: "data/ground_station.csv"