verschil in uitkomst /Analysis/Allocatie/StartState_metBAGnieuwbouw/Subsector_rel tussen Azure geodms-p0 en geodms-d #838

basvanbemmel · 2024-11-22T11:48:07Z

GeoDMS 15.10.2
PD: https://pbl.sliksvn.com/ruimtescanner/PBL/ProjDir/branches/WLO2024 rev11310
SD: https://pbl.sliksvn.com/ruimtescanner/PBL/SourceData/Trunk/RSL rev11303
BaseData, VariantData en Allocatie uitgerekend met RunAll.cmd

item: /Analysis/Allocatie/StartState_metBAGnieuwbouw/Subsector_rel
/BaseData/BAG_nieuwbouw/Result/Read_UNCHECKED/Werken/Overheid_kw_diensten
/Analysis/Allocatie/StartState_metBAGnieuwbouw/CompactedBBB/Werken/Overheid_kw_diensten

Er is een verschil te zien tussen bijvoorbeeld WLO_hoog_BAU/Zichtjaren/Y2030/Sector_rel_Verstedelijking

Zwart beide computers verstedelijking in 2030, groen niet verstedelijkt op geodms-d tov p0, rood verstedelijkt op geodms-d maar niet op geodms-p0

screendump in gesprek linkerscherm de geodms-d

screendump in gesprek rechterscherm de p-0

De aangemaakte tifs in LD (PD en SD zijn dus hetzelfde)
Overheid_kw_diensten.zip

Het writen van de bestanden gebeurd in:
BaseData/BAG_nieuwbouw/Result/Write/Werken/Overheid_kw_diensten

in ArcGIS zien bestanden hetzelfde uit, bestandsgrootte is wel anders:

BAG_nieuwbouw.dms
container Write :=
for_each_nedvna(
Classifications/StandVar_Prep/path
, 'BAG_nieuwbouw/'+Classifications/StandVar_Prep/Path
, AdminDomain
, Classifications/StandVar_Prep
, Classifications/StandVar_Prep/unit_name
, '%LocalDataProjDir%/BaseData/BAG_Nieuwbouw/'+Classifications/StandVar_Prep/Path+'.tif'
)//, using = "CaseClassifications/Vastgoed/OP"
{
parameter Generate := 'Ready', ExplicitSuppliers = "=AsList(Classifications/Standvar_Prep/path, ';')";
}

specs p0:
Windows Server 2019 Datacenter
AMD EPYC 7763 64-Core Processor 2.44 GHz
256GB
64 bits

specs d:
Windows Server 2019 Datacenter
AMD EPYC 7763 64-Core Processor 2.44 GHz
512 GB
64 bits

debug code in ..\WLO2024\cfg\main\Analysis\Allocatie,dms (vanaf regel 20)

	container NotZero :=  for_each_nedv(Sector/XSubsector/name,
		'value(BaseData/BAG_nieuwbouw/Result/read/'+Sector/XSubsector/name+',float32) != 0f',
		AdminDomain, bool
	);
	container CompactedBBB :=  for_each_nedv(Sector/XSubsector/name,
		'NotZero/'+Sector/XSubsector/name+' ? value(BaseData/BAG_nieuwbouw/Result/read/'+Sector/XSubsector/name+',float32) : 0f/0f',
		AdminDomain, float32
	);
	container CompactedXXX :=  for_each_nedv(Sector/XSubsector/name,
		'collect_by_cond(CompactedAdminDomain, AdminDomain/IsCompactedDomain, CompactedBBB/'+Sector/XSubsector/name+')',
		CompactedAdminDomain, float32
	);
		
	attribute<Sector/XSubsector> Subsector_rel (CompactedAdminDomain) := ='argmax_ifdefined('+AsList('CompactedXXX/'+Sector/XSubsector/name, ',')+')';

org:

attribute<Sector/XSubsector> Subsector_rel (CompactedAdminDomain) :=
= 'argmax_ifdefined(
'+AsList('collect_by_cond(CompactedAdminDomain, AdminDomain/IsCompactedDomain, value(BaseData/BAG_nieuwbouw/Result/read/'+Sector/XSubsector/name+',float32) != 0f ? value(BaseData/BAG_nieuwbouw/Result/read/'+Sector/XSubsector/name+',float32) : 0f/0f)', ',')+'
)';

The text was updated successfully, but these errors were encountered:

basvanbemmel · 2024-11-22T11:49:01Z

geodms-d:

geodms-p0

MaartenHilferink · 2024-11-22T12:06:05Z

Ik zal met Jip naar de generatie van deze TIFS kijken. De 1.45E-41 waarde blijft heel verdacht.

basvanbemmel · 2024-11-22T12:07:01Z

In GUI runnen van BaseData/BAG_nieuwbouw/Result/Write/Werken/Overheid_kw_diensten op de geodms-p0 geeft wel hetzelfde bestand als op de geodms-d, zei screendump. Probleem moet dan in de batch zitten?

MaartenHilferink · 2024-11-22T12:14:30Z

Of in het (niet) opschonen van eerdere resultaten. Welke batch file had je gedraaid ?

basvanbemmel · 2024-11-22T12:24:17Z

.

basvanbemmel · 2024-11-22T12:29:28Z

RunAll.cmd
er lijkt dus een verschil tussen beide computers bij het draaien van de batch wat zich niet uit in de GUI als je daar het item uitrekent.
dus test is:
reken in GUI uit:
/BaseData/BAG_nieuwbouw/Result/Write/Werken/Overheid_kw_diensten
reken in batch uit:
RunAll.bat dan gaat het eigenlijk om
/MaakBasedata/Generate_Run1

op de p0 zie ik dan dus een verschil in de bestanden wat niet het geval is op de geodms-d

MaartenHilferink · 2024-11-22T15:08:40Z

Jip heeft net een wellicht vergelijkbare situatie gezien, waarin schrijven via native tiff (dus niet gdalwrite.grid) steeds volgende pagina's schrijft en bij inlezen steeds de 1e pagina gelezen wordt. Wellicht was voor het runnen op de gemankeerde machine niet alle tussenresultaten weggegooid en daar door TIF groter geworden in plaats van overschreven.

MaartenHilferink · 2024-11-22T15:32:22Z

Had je voorafgaande aan vanuit GUI schrijven eerst de file weggegooid in explorer/commander ? Wellicht moeten we dat voortaan ook in batch files beter opnemen. Dit hangt mede samen met niet meer naar .tmp schrijven van wijzigingen, zie #582, #820

basvanbemmel · 2024-11-23T05:45:11Z

Het is allemaal uitgevoerd op gehele lege LD's voor de betreffende cfg in 15.10.2. SD en PD ook dezelfde versie. Ik heb het ook nog op de geodms-p2 getest (machine conform p0). Het probleem lijkt dus te focussen op verschil in het bestand Overheid_kw_diensten.tif in ..\LD\wlo2024\BaseData_GUI\BAG_Nieuwbouw\Werken

Alleen dit bestand is afwijkend of je het in de GUI berekend of in de batch
GUI activeren item: /MaakBasedata/Generate_Run1 (het probleemitem is dus eigenlijk /BaseData/BAG_nieuwbouw/Result/Write/Werken/Overheid_kw_diensten die in Generate_Run1 wordt aangeroepen )

Batch: RunAll.cmd

links GUI resultaat, rechts batch-resultaat in totalcommander

Ik denk niet dat het met de tmp-bestanden te maken heeft eigenlijk. Toch meer iets van afronding van 0 waarden die niet exact hetzelfde gaat voor de GUI en de batch specifiek voor dit item/bestand en op deze computers

Als je een verschilgrid maakt (door de 2 bestanden weer in te lezen) van de 2 bestanden krijg je

	attribute<float32> Overheid_kw_diensten (AdminDomain)
	:	StorageName     = "K:/20241122/Overheid_kw_diensten.tif"
	,	StorageType     = "gdal.grid"
	,	StorageReadOnly = "True";

	attribute<float32> Overheid_kw_diensten_GUI (AdminDomain)
	:	StorageName     = "K:/20241122/Overheid_kw_diensten_GUI.tif"
	,	StorageType     = "gdal.grid"
	,	StorageReadOnly = "True";

	attribute<float32> verschil (AdminDomain):=Overheid_kw_diensten - Overheid_kw_diensten_GUI;

basvanbemmel · 2024-11-23T07:15:13Z

Ook op mijn lokale laptop verschil

basvanbemmel · 2024-11-26T08:04:57Z

En hebben jullie hier al naar kunnen kijken?

MaartenHilferink · 2024-11-27T14:30:12Z

Ik ga nu proberen te reproduceren op mijn machine.

basvanbemmel · 2024-11-27T14:34:08Z

ok succes ermee. mocht je hulp nodig hebben dan hoor ik het graag

MaartenHilferink · 2024-11-27T16:40:20Z

1e reproductiepoging:

Met GUI en RunAll.bat geproduceerde files op OVSRV08 zijn wel even groot:

MaartenHilferink · 2024-11-27T17:19:25Z

Met GUI geproduceerde file, nadat deze al met RunAll.bat geproduceerd was:

basvanbemmel · 2024-11-27T18:15:17Z

nog voor de duidelijkheid ik had dus 3 systemen waarbij het resultaat verschillend was tussen GUI aanmaak en batch aanmaak:

mijn desktop computer
mijn laptop
Azure p0
Ik rename nadat ik gerund heb de gehele map (lokale cfg map)
Opvallend is dat het bestand Overheid_kw_diensten.tif op de verschillende systemen ook nog eens niet dezelfde bestandsgrootte hebben.

Allleen de geodms-d liet dus hetzelfde resultaat zien tussen GUI en batch

Je tweede opmerking lijkt erop dat de stream niet goed afgesloten wordt immers bestandsgroote is exact tweemaal zo groot. Dat lijkt wellicht weer een ander probleem?

MaartenHilferink · 2024-11-28T10:11:31Z

Ik heb nu met 3 versies van de TIF getest op OVSVR08: met GUI gemaak, met batch gemaakt, met batch en daarna met GUI gemaakt. Alledrie geven dit resultaat:

MaartenHilferink · 2024-11-28T10:13:39Z

Het herhaald schrijven (zonder tussentijds file weg te halen) resulterend tot 2x de bestandsgrootte is inderdaad waarschijnlijk een ander issue, gerelateerd aan het niet meer naar een .tmp schrijven.

basvanbemmel · 2024-11-28T10:16:39Z

Wat bedoel je eigenlijk met "3 versies van de TIF", is het niet veel interessanter om het ook op een geheel ander systeem te proberen (lokale laptop bijvoorbeeld). Dat is wel te runnen overigens (aanmaak zit helemaal aan de voorkant van de batch)

MaartenHilferink · 2024-11-28T10:38:47Z

Ter verduidelijking, op geodms-p2 was links met GUI gemaakt: 4,195,888 bytes en rechts met batch 3,553,848 bytes.
op je lokale laptop links met GUI: 3,553,936 bytes en rechts met batch: 4,196,056 bytes.

MaartenHilferink · 2024-11-28T10:48:01Z

Het lukt mij hier niet om zo'n 4MB tif te maken. Kun je me er 1 mailen ? Dan ga ik het eens binair en met GeoDMS / q-gis vergelijken. Ik neem aan dat de 3.5 MB versies van de $MB versies verschillen in dat de 4MB die kleine waarden bevatten die in de 3.5 MB versies 0 zijn, maar wil beter kijken naar welke kleine waarden. M.b.t. de overige verschillen in file-sizes acht ik de volgende suggesties waarschijnlijk:

...

...

basvanbemmel · 2024-11-29T10:21:52Z

ik check eerst wat oplossing #841 oplevert

basvanbemmel · 2024-11-30T09:00:36Z

in 16.0.2 opgelost op computer geodms-p0

Links in batch berekend, rechts in GUI berekend

basvanbemmel assigned MaartenHilferink Nov 22, 2024

MaartenHilferink assigned jipclaassens Nov 22, 2024

MaartenHilferink mentioned this issue Nov 22, 2024

Writing to file, creating .tmp, then alt+r (or close app) doesn't always result a rename of .tmp file #582

Closed

MaartenHilferink mentioned this issue Nov 28, 2024

verschil in uitkomst tussen 15.10.2, 16.0.0 en 16.0.1 #841

Closed

MaartenHilferink closed this as completed in 9c03011 Nov 29, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

verschil in uitkomst /Analysis/Allocatie/StartState_metBAGnieuwbouw/Subsector_rel tussen Azure geodms-p0 en geodms-d #838

verschil in uitkomst /Analysis/Allocatie/StartState_metBAGnieuwbouw/Subsector_rel tussen Azure geodms-p0 en geodms-d #838

basvanbemmel commented Nov 22, 2024 •

edited

Loading

basvanbemmel commented Nov 22, 2024

MaartenHilferink commented Nov 22, 2024

basvanbemmel commented Nov 22, 2024

MaartenHilferink commented Nov 22, 2024 •

edited

Loading

basvanbemmel commented Nov 22, 2024 •

edited

Loading

basvanbemmel commented Nov 22, 2024 •

edited

Loading

MaartenHilferink commented Nov 22, 2024

MaartenHilferink commented Nov 22, 2024

basvanbemmel commented Nov 23, 2024

basvanbemmel commented Nov 23, 2024

basvanbemmel commented Nov 26, 2024

MaartenHilferink commented Nov 27, 2024

basvanbemmel commented Nov 27, 2024

MaartenHilferink commented Nov 27, 2024

MaartenHilferink commented Nov 27, 2024

basvanbemmel commented Nov 27, 2024 •

edited

Loading

MaartenHilferink commented Nov 28, 2024

MaartenHilferink commented Nov 28, 2024

basvanbemmel commented Nov 28, 2024

MaartenHilferink commented Nov 28, 2024

MaartenHilferink commented Nov 28, 2024 •

edited

Loading

basvanbemmel commented Nov 29, 2024

basvanbemmel commented Nov 30, 2024

verschil in uitkomst /Analysis/Allocatie/StartState_metBAGnieuwbouw/Subsector_rel tussen Azure geodms-p0 en geodms-d #838

verschil in uitkomst /Analysis/Allocatie/StartState_metBAGnieuwbouw/Subsector_rel tussen Azure geodms-p0 en geodms-d #838

Comments

basvanbemmel commented Nov 22, 2024 • edited Loading

basvanbemmel commented Nov 22, 2024

MaartenHilferink commented Nov 22, 2024

basvanbemmel commented Nov 22, 2024

MaartenHilferink commented Nov 22, 2024 • edited Loading

basvanbemmel commented Nov 22, 2024 • edited Loading

basvanbemmel commented Nov 22, 2024 • edited Loading

MaartenHilferink commented Nov 22, 2024

MaartenHilferink commented Nov 22, 2024

basvanbemmel commented Nov 23, 2024

basvanbemmel commented Nov 23, 2024

basvanbemmel commented Nov 26, 2024

MaartenHilferink commented Nov 27, 2024

basvanbemmel commented Nov 27, 2024

MaartenHilferink commented Nov 27, 2024

MaartenHilferink commented Nov 27, 2024

basvanbemmel commented Nov 27, 2024 • edited Loading

MaartenHilferink commented Nov 28, 2024

MaartenHilferink commented Nov 28, 2024

basvanbemmel commented Nov 28, 2024

MaartenHilferink commented Nov 28, 2024

MaartenHilferink commented Nov 28, 2024 • edited Loading

basvanbemmel commented Nov 29, 2024

basvanbemmel commented Nov 30, 2024

basvanbemmel commented Nov 22, 2024 •

edited

Loading

MaartenHilferink commented Nov 22, 2024 •

edited

Loading

basvanbemmel commented Nov 22, 2024 •

edited

Loading

basvanbemmel commented Nov 22, 2024 •

edited

Loading

basvanbemmel commented Nov 27, 2024 •

edited

Loading

MaartenHilferink commented Nov 28, 2024 •

edited

Loading