add file config example with the configs

[yhmtsai]

This PR adds the example to show the solver configuration based on the file.
This PR aims to set up config close to the existing example without any registry usage.
Note. the stopping criterion is different among these configs.

• cg.json: simple-solver
• blockjacobi-cg.json: preconditioned-solver
• ir.json: iterative-refinement
• parilu.json: ilu-preconditioned-solver (by using factoization parameter directly)
• pgm-multigrid-cg.json: multigrid-preconditioned-solver (set min_coarse_rows additionally due to this small example matrix)
• mixed-pgm-multigrid-cg.json: mixed-multigrid-preconditioned-solver (assuming there are always more than one level)

There will be another one example to show the registry usage.

[MarcelKoch]

LGTM. I would prefer the json files merged.

[MarcelKoch]

IMO, all json files should be merged, and the filenames should be keywords instead. I think that is more realistic for acutal usecases.

[yhmtsai]

I thought user usually swap the file to choose the solver, which gives less confusing.

[MarcelKoch]

I would think a single file is less confusing, since it's only one file, where the keys are the previous filenames, and you can add comments for each configuration. (Ofc not in JSON, but that is arguably not a good format for this use case anyway.)

[thoasm]

After reading through this PR, I agree with @yhmtsai.
Having one file per configuration is much simpler because it makes it easier to swap them around.
Additionally, it is easier to understand when reading the code, which is important for this example.

[MarcelKoch]

You could output the json directly:

std::cout << std::setw(4) << nlohman::json::parse(configfile) << std::endl;

see: https://json.nlohmann.me/api/operator_ltlt/
Of course, it would make more sense if the json object was stored already before.

[yhmtsai]

Thanks for this information.
I will put it when we have the example with loading json object before

[thoasm]

Right now, I only comment until the discussion is resolved.
I would like all configuration files to be tested and part of the CI.
Other than that, I only have nits.

[thoasm]

After reading through this PR, I agree with @yhmtsai.
Having one file per configuration is much simpler because it makes it easier to swap them around.
Additionally, it is easier to understand when reading the code, which is important for this example.

[thoasm]

My main concern is that this only tests a single file as part of our automatic tests. It doesn't check the other files, so we couldn't detect if we broke the compatibility.

[yhmtsai]

I am not sure whether using examples as kind of integration test is a good idea.
I have add the test to check they can be runnable

[thoasm]

Does this mean they are not run as part of our CI?
Is there a reason why we don't?

[yhmtsai]

I have added test which only checks it can run properly.

[yhmtsai]

I do not reuse the existing one because it needs to accept additional parameter

[MarcelKoch]

I still think that

1. JSON is not the right format
2. The files should be combined, and annotated with comments

But I won't hold up the PR.

[MarcelKoch]

you also need to add the file to doc/examples/examples.hpp.in