Object oriented refactoring of fcType

[michelebucelli]

Problem

As part of my work on #519, I was going to implement a concrete active stress class (UniformUnsteadyActiveStress) that replicates what is currently implemented by the <Fiber_reinforcement_stress> tag, that is reads a time-dependent active tension transient from file.

It seems to me that the natural way of doing this is to place an object of type fcType inside UniformUnsteadyActiveStress, construct that object as part of the active stress object initialization, and evaluate it as part of the active tension evaluation method.

However, I encountered a few issues which I think are worth addressing in a more focused refactoring of fcType:

1. fcType is defined in ComMod.h, but I cannot include ComMod.h in active_stress.h (or derived), due to circular dependencies. This can probably be worked around with forward declarations and access through a pointer, but it feels needlessly convoluted.
2. ifft takes in input a ComMod instance, even though it only uses its time member. It would be more natural for ifft to take the evaluation time directly.

Solution

The issues above prompted me to think about a cleaner restructuring of the whole fft, ifft and fcType infrastructure, which I think is worth addressing independently of #519, since it's more general.

I propose the following changes:

1. move fcType to its own file, so that it can be included and used independently of ComMod.h;
2. encapsulate reading data from file and calling fft as a method of the fcType class; this might be done either in the class constructor or in an initialization method (I lean in favor of the constructor);
3. modify ifft so that it only takes the desired time in input, not the whole ComMod;
4. encapsulate evaluating the interpolated data at a given time point as a method of the fcType class, say fcType::evaluate.

After these changes, fft and ifft would become internal implementation details of fcType, so their code could be moved to that class.

Additionally, I suggest taking the opportunity to give the fcType class a more explicit name (I figure that fc stands for Fourier coefficients, but that might not be immediately obvious to someone unfamiliar with the code). I suggest for example FourierInterpolation or TimeInterpolation (I slightly lean in favor of the latter, because it leaves open the possibility of expanding the class to include other interpolation methods, e.g. splines or piecewise linear, while retaining the same interface).

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

[ktbolt]

@michelebucelli I think your plan is excellent; we do want to move all classes out of ComMod.h into their own files and give them a descriptive name, add methods, etc.

In Solution 2: encapsulate reading data a from file do you mean to add a method to the fcType class to read fft data ? It is better not to have a class perform I/O to read the files used to set their data; just pass the data in a method.

And assign yourself to this Issue if you are planning on doing the implementation.

[michelebucelli]

In Solution 2: encapsulate reading data a from file do you mean to add a method to the fcType class to read fft data ? It is better not to have a class perform I/O to read the files used to set their data; just pass the data in a method.

Yes, that is what I meant.

I generally agree. Here I suggested encapsulating the I/O because reading the data here is less than trivial (i.e. it's not just dumping the contents of a file, but there's also a bit of parsing and correctness checks), and is currently replicated, with subtle changes, in two or three places.

A possible solution could be to have fcType take the data as constructor argument, and move reading that data to a dedicated function, let's say

std::vector<std::pair<double, double>>
read_time_series_file(const std::string &file_name)

Then one could do

fcType fc(read_time_series_file(file_name));

which I think looks clean, while still supporting initialization from raw data if needed.

[ktbolt]

@michelebucelli I think fcType should take the data as constructor argument, and move reading that data to a dedicated function.

We do need to clean up the text file parsing code.