vermaseren / form

The FORM project for symbolic manipulation of very big expressions
GNU General Public License v3.0
985 stars 118 forks source link

ParFORM redefine bug with more than one expressions #525

Open tueda opened 1 month ago

tueda commented 1 month ago

Minimized example from the ParFORM issue in https://github.com/vermaseren/form/pull/524.

mpirun -np 3 parform freezes with the following input:

L F1 = 1;
L F2 = 1;
.sort
#define flag "0"
if (expression(F1)) redefine flag "1";
.sort
#if `flag'
.sort
#endif
.end
tueda commented 1 month ago

There are 3 basic strategies to handle redefine in parallelisation:

  1. Modify a redefined preprocessor variable with synchronisation, as TFORM does.
  2. Synchronise redefined preprocessor variables at the end of processing each expression.
  3. Synchronise redefined preprocessor variables at the end of a module.

The current implementation of ParFORM tries to adopt option 3 for efficiency while at the same time trying to resemble TFORM code to share some variables and code (see also 23285ec785d3a3659d7b7551b7ab96333ed58cff). As a result(?), it gathers redefined variables after each expression is processed, and broadcasts them at the end of the module. But, with more than one expression, the information gathered after finishing an expression that indicates which variables are redefined (stored in AC.inputnumbers on the rank 0 process) is cleared at the beginning of processing the next expression (in DoExecute()).

A natural solution would be to move the broadcast to the end of processing each expression, rather than the end of the module.

It may be an option to gather redefined variables at the end of the module (and then broadcast them), but then the meaning of inputnumbers (is the last ninterms, which is reset at the beginning of processing each expression) becomes more obscure.