Inconsistent Evaluation Results for Referencing .crg Files in OpenCRG

[tschierz]

There exists a bug in OpenCRG affecting the evaluation of referencing .crg files.

Issue Summary
When a wrapper .crg file references a data .crg file via file references, evaluation results are not consistent with those obtained by evaluating the data .crg file directly. Differences appear at the 15th decimal place, but accumulate to non-negligible errors in simulation contexts.

Root Cause
The discrepancy originates in crgDataEvaluv2z, where evaluation differs based on admin.defMask. Specifically, the feature flag dCrgDataDefVIndexIt is part of $KD_DEFINITION, which can only be defined in the data .crg file — not in the wrapper. As a result, the admin.defMask of the referenced .crg file is not propagated to the referencing .crg file, making bit-identical evaluation impossible with the current implementation.

Reproduction
Test data with standalone example code is available on request to reproduce this behavior.

Request
Please fix the propagation of the admin.defMask from the referenced data .crg file to the referencing wrapper .crg file during evaluation setup, enabling consistent and bit-identical results regardless of whether a wrapper or data .crg file is evaluated directly.

[jorauh]

The expectation that floating-point arithmetic will yield bit-for-bit identical results is generally unrealistic. Different computer hardware, different compilers, and even different compiler flags often lead to discrepancies, though these should not be relevant for practical applications. If this results in a cumulative error, the problem often lies in the formulation of the solution approach.

I am not sure if there is a bug, or if your way to use the c-api is somewhat beyond the intended standard and it's sample implementation in the c-api. The OpenCRG FILEREF feature is only intended to replace or add modifier and/or option sections of the referenced .crg file containing the data.

The documentation of this feature will be fixed in v2.0.1 (#59) to be consistent to previous documentations, existing implementations and the samples in crg-txt/fileref*.crg .

To get more insight, @tschierz please provide your test data and example code.

[tschierz]

Please note, that this is not regarding running OpenCRG on different platforms or with different builds (compilers) that obviously do not evaluate bit identical. The issue described here is regarding the evaluation of crg files.

Example:

• file1: belgian_block.crg (direct approach)
• file2: wrapper.crg - that references the same belgian_block.crg via $ROAD_CRG_FILE (indirect approach)

The expectation is to have the same results for z, when evaluating the crg files with identical u,v values since we are evaluating the same underlying crg file data (i.e. belgian_block). The only difference is, that one file uses the fileref feature.

@jorauh: I have provided the full data by external file share accordingly.

[jorauh]

OpenCRG_FileRefIssue_standalone.zip was provided by @tschierz as OpenCRG_FileRefIssue_standalone.7z. I further zip-ped it because github does not accept .7z :-(

[CarawaySeed42]

Nevermind the tiny evaluation differences in the provided example, but overwriting the referenced crg file's admin structure with the "empty" one from the referring crg file seems to be odd.

@jorauh Do you perhaps know why this is done the way it is? Because the crg file that is referenced has all the information about its data.
In the above case, the evaluation assumes the v-spacing is irregular when using fileref although it isn't.
Another example would be if the crg had a slope, using fileref would result in forward integration of refline Z and using the original file, forward and backwards integration is used.

So why is this information thrown away? This leads to different evaluation branches being taken, compared to when loading the original file.

A comparison to the Matlab reader would also be advised.
Edit: The Matlab does not exhibit this issue, because it just replaces the mods and opts of the referenced file as it is supposed to.

OpenCRG/c-api/baselib/src/crgLoader.c

Lines 3380 to 3395 in 2530b4e

	/* hold a copy of the administration structure */
	memcpy( &adminBackup, &( crgData->admin ), sizeof( CrgAdminStruct ) );
	crgData->admin.sectionType = dFileSectionNone;
	/* load the include file and set the file level accordingly */
	mFileLevel++;
	result = crgLoaderAddFile( filename, &crgData );
	mFileLevel--;
	if ( !result )
	return 0;
	/* restore the administration structure */
	memcpy( &( crgData->admin ), &adminBackup, sizeof( CrgAdminStruct ) );

[CarawaySeed42]

@tschierz
There is a pending PR that would fix this issue if there are no complaints or objections ( #132 )

[tschierz]

@CarawaySeed42: Thanks for the fix. I have tested it and it solves the issue for my use case described above.