Allowing Infinity and NaN values

[thealanjason]

Based of UM-Bridge/UMBridge.jl#25

Problem:

It is possible that models run with given inputs (numbers) and evaluate to inf, -inf or nan values (non-numbers). Based on these values, we can take a decision in the UQ algorithm.
Currently, Umbridge does not fully support this.

Solution:

Add feature to allow serializing(write) and deserializing(read) Infinity and NaN values, and provide a global mechanism (flag) to activate the feature.

Some Context:

Python Implementation

• we use here the .json() function from the requests package.
• the .json() function uses loads() or dumps() from complexjson package, which finally uses loads() or dumps() from the default json python package
• the dumps() function has allow_nan argument which enables writing the Infinity or NaN values to the JSON string. The default value is True
• the loads() function has parse_constant argument, which can allow using a function to read the Infinity or Nan values from the JSON string. The default function is however None. A solution to allow reading Infinity and NaN is here: https://stackoverflow.com/a/62685520
• TLDR, currently if we use both a python server and client, the server will write these values to the JSON string, but the client will not be able to read them.

Julia Implementation

• we use here the .json() functin from the JSON package.
• the .json() function uses a StandardSerializer which does not support reading/writing of Infinity and NaN values.
• this PR adds the functionality to write Infinity and NaN values. Whether it can handle reading them as well, needs to be tested

C++ Implementation (edited by @chun9l)

• There is a wrapper function here that calls json::parse in the JSON header file.
• The JSON library does not support NaN or Inf natively. However, their .dump() function converts NaNs into null; see here.
• Currently unclear if there exists an easy way to enable handling of these value.

[thealanjason]

In the Umbridge project for the basic usage (excluding load-balancing), there are 4 possibilities to parse numerical data:

1. Request - UQ write
2. Request - Model read
3. Response - Model write
4. Response - UQ read

If we think this through:

UQ algorithms will (almost) always provide input as numbers.
But Models always require the input to be numbers and providing a Model non-numerical input may not even make sense. However, Models may or may not always have the output -- evaluate/gradient/jacobian/hessian -- as a number. For example, they may fail to evaluate, they may evaluate but blow-up and result in non-numerical values.

Assuming that the above two statements are true, we would only need the following two operations to handle Infinity and NaN values:

1. Response - Model write
2. Response - UQ read