Laufzeit Modell

[phiola]

Modellparameter zur Einstellung der Laufzeit des Modells (in Jahren) erstellen.

[dunland]

• [x] @dunland: dynamische anzeige der % in infoscreen (übergebe % direkt von frontend)

[dunland]

• [ ] mit Torben bzw. R&E besprechen

[lwinkeler]

Auswahl möglich:

• 2020-2030
• 2020-2040
• 2020-2045

Einstellung via initial_values.csv auf Seafile/Q-Scope_data/includes/csv-data_technical Aktuell keine Änderung -> 2020-2045

[dunland]

1. sind die vorausgehenden Leerzeichen in initial_variables.csv in den header-Spalten wichtig? hat mich kirre gemacht bis ich gecheckt habe, dass da Leerzeichen sind.. ;) Ich habe sie mal entfernt, da in GAMA ja scheinbar ohnehin csv-Abruf über Indizes erfolgt.. edit: die ganze csv hat ja überall leading spaces! aah

2. Ich brauche die Laufzeit in Anzahl der steps. Wie kommen wir bei 2020-2045 eigentlich auf ~9496~? edit: 9132 :fearful: (2045-2020) * 365 = 9490 Wo kommen die ~übrigen 6 steps (Tage)~ her? edit: es sind jetzt irgendwie 358 zu wenig. genau ein Jahr minus eine Woche! ebenso: '2020-2030' ergibt 3653 cycles, statt wie erwartet 3650 '2020-2040' ergibt ebenfalls 3653 cycles (siehe unten), anstatt wie erwartet 9490

3. die else-Schleife für den "Ausweg" 2045 funktioniert nicht. Bei Eingabe 2020-2045 lande ich trotzdem bei 3653 cycles.

[lwinkeler]

2. Soweit ich weiß rechnet GAMA Schaltjahre mit ein
   • 2020
   • 2024
   • 2028
   • 2032
   • 2036
   • 2040
   • 2044

Wenn ich es über das Frontend von GAMA starte (im pre_main) funktioniert alles und es entstehen folgende Anzahlen an cycles: 2020-2030 (10 x 365 + 3) -> 3653 cycles ☑ 2020-2040 (20 x 365 + 5) -> 7305 cycles ☑ 2020-2045 (20 x 365 + 7) -> 9132 ☑

[lwinkeler]

3. GAMA führte bisher noch string model_runtime_string <- string(get_initial_value("model_runtime")); aus -> "model_runtime_string ☑

Dennoch erwies sich das Auslesen von initial_variables.csv als fehlerhaft ‼️

• es scheint, dass alle zuvor ausgelesenen Variablen, welche anschließend im experiment-Bereich als Parameter definiert werden überspielt werden -> über die dort zugewiesenen :among-Bereiche
• Zusammenhang mit issue #76?

---

• [ ] Lösungsweg definieren!

[dunland]

Eine Lösung könnte sein, die Variablen unten umzubenennen:

global{
...
int global_neighboring_distance <- int(get_initial_value("global_neighboring_distance"));
int global_neighboring_distance_experiment;
...
}

experiment debug type:gui {
...
parameter "Neighboring distance" var: global_neighboring_distance_experiment <- global_neighboring_distance min: 0 max: 5 category: "Communication";
...
}

So schafft es "global_neighboring_distance" zumindest in die Output Console, aber ich weiß nicht, ob der Wert auch korrekt angewandt wird (Communication->Neighboring distance steht auf 0 statt wie in der csv auf 2)

[phiola]

Ich hab das Problem jetzt gelöst, indem ich typenspezifische Varianten der Funktion get_initial_value angelegt hab. Aus irgendeinem Grund werden die Parameter jetzt richtig zugewiesen. Nach wie vor werden sie im GUI aber nicht korrekt angezeigt. Das scheint aber ein GAMA-Problem zu sein, das immer auftritt, wenn man einem Parameter einen Wert über eine selbst definierte Funktion zuweist.

[dunland]

auf warning_fixes:

experiment debug type:gui {
    parameter "Influence of private communication" var: private_communication min: 0.0 max: 1.0 category: "Decision making";
    parameter "Energy Efficient Habits Threshold for Change Decision" var: change_threshold category: "Decision making";
    parameter "Chance to convince landlord for connection of Q100 heat network" var: landlord_prop category: "Decision making";
    parameter "Neighboring distance" var: global_neighboring_distance min: 0 max: 5 category: "Communication";
    parameter "Influence-Type" var: influence_type <- "one-side" among: ["one-side", "both_sides"] category: "Communication";
    parameter "Memory" var: communication_memory <- true among: [true, false] category: "Communication";
    parameter "New Buildings" var: new_buildings_parameter <- "none" among: ["at_once", "continuously", "linear2030", "none"] category: "Buildings";
    parameter "Random Order of new Buildings" var: new_buildings_order_random <- true category: "Buildings";
    parameter "Modernization Energy Saving" var: energy_saving_rate category: "Buildings" min: 0.0 max: 1.0 step: 0.05;
    parameter "Shapefile for buildings:" var: shape_file_buildings category: "GIS";
    parameter "Building types source" var: attributes_source <- "Kataster_A" among: ["Kataster_A", "Kataster_T"] category: "GIS";
    parameter "3D-View" var: view_toggle category: "GIS";
    parameter "Alpha scenario" var: alpha_scenario <- "Static_mean" among: ["Static_mean", "Dynamic_moderate", "Dynamic_high", "Static_high"] category: "Technical data";
    parameter "Carbon price scenario" var: carbon_price_scenario <- "A - Conservative" among: ["A - Conservative", "B - Moderate", "C1 - Progressive", "C2 - Progressive", "C3 - Progressive"] category: "Technical data";
    parameter "Energy prices scenario" var: energy_price_scenario <- "Prices_Project start" among: ["Prices_Project start", "Prices_2021", "Prices_2022 1st half"] category: "Technical data";
    parameter "Q100 OpEx prices scenario" var: q100_price_opex_scenario <- "12 ct / kWh (static)" among: ["12 ct / kWh (static)", "9-15 ct / kWh (dynamic)"] category: "Technical data";
    parameter "Q100 CapEx prices scenario" var: q100_price_capex_scenario <- "1 payment" among: ["1 payment", "2 payments", "5 payments"] category: "Technical data";
    parameter "Q100 Emissions scenario" var: q100_emissions_scenario <- "Constant_50g / kWh" among: ["Constant_50g / kWh", "Declining_Steps", "Declining_Linear", "Constant_ Zero emissions"] category: "Technical data";
    parameter "Carbon price for households?" var: carbon_price_on_off <- false category: "Technical data";
    parameter "Seed" var: seed <- seed category: "Simulation";
    parameter "Keep seed" var: keep_seed <- false category: "Simulation";
}

['global_neighboring_distance',0,'int','2']
['energy_saving_rate',2,'float','0.5']
['landlord_prop',5,'float','0.1']
['change_factor',3,'float','0.9']
['change_threshold',4,'float','4.75']
['feedback_factor',7,'float','1.2']
['MFH_connection_threshold',6,'float','0.8']
['B_feedback',8,'bool','true']
['view_toggle',9,'bool','false']
['share_families',11,'float','0.17']
['share_socialgroup_families',16,'float','0.75']
['share_socialgroup_nonfamilies',12,'float','0.29']
['private_communication',13,'float','0.25']

[dunland]

https://github.com/lwinkeler/q100_abm_qscope-workshop/commit/0a8d4d1df0d03ab64e3b0de64fc39fbf62dc023a Ich möchte noch hinzufügen: der Anschlusszeitpunkt wird nun doch absolut als Jahreszahl übergeben (nicht nach dem Schema Jetzt + X Jahre). Wenn kein Anschluss definiert ist wird "false" übergeben (was auch als 0 interpretiert werden kann). Da die Jahreszahl niemals == 0 ist, sollte das kein Problem sein. Hoffe ich!