10_feature
Important
Visit https://aerosand.cc for the latest updates.
0. Preface
The previous discussion achieved reading parameter values by keyword, but as we mentioned, the string type does not meet practical application requirements. This section will further explore the self-developed library.
This section primarily discusses:
- Understanding the use of template classes
- Adding dictionary comments and error reporting mechanisms
- Compiling and running a feature project
1. Project Preparation
We will copy the previous project to create this project.
Run the following commands in the terminal to create this project by copying:
ofsp
cp -r ofsp_10_keyword ofsp_10_feature
code ofsp_10_featureRun the following commands in the terminal to clean and modify the project:
wclean IOdictionary
wclean
mv ofsp_09_keyword.C ofsp_10_feature.C
sed -i s/"09_keyword"/"10_feature"/g Make/filesThe project file structure at this point is as follows:
├── IOdictionary
│ ├── IOdictionary.C
│ ├── IOdictionary.H
│ └── Make
│ ├── files
│ └── options
├── Make
│ ├── files
│ └── options
├── ofsp_10_feature.C
└── ofspPropertiesRun the following commands in the terminal to test whether the modified project is correct:
wmake IOdictionary
wmake
ofsp_10_featureThe results show that the project is functioning normally.
2. Distinguishing Parameter Types
After obtaining the return value of type string, we need to further convert it to the required data type. Templates can be used for this development.
2.1. Development Improvements
The class declaration in IOdictionary.H has been improved as follows:
| |
Caution
Note that due to the different compilation mechanism of templates, we have placed the definition and declaration of the template member functions in the same file. Separating them would cause the main program to fail to find the instantiated objects of the functions. Since this involves more C++ knowledge, we will not delve into it here; it is sufficient to know that this approach works.
The class definition in IOdictionary.C has been improved as follows:
| |
The main source code in ofsp_10_feature.C has been improved as follows:
| |
2.2. Testing
The content of the dictionary file ofspProperties is as follows (located at /ofsp/ofsp_10_feature/ofspProperties):
nu 0.01
application laplacianFoam
deltaT 0.005
writeInterval 20
purgeWrite 0Run the following commands in the terminal to compile and run:
wmake IOdictionary
wmake
ofsp_10_featureThe terminal output is as follows:
nu 0.01
application laplacianFoam
deltaT 0.005
writeInterval 20
purgeWrite 0
Write time interval = 0.1It can be seen that the reading functionality works normally, and the calculation verifies that the types of the read parameter values are correct.
3. Style and Error Reporting Mechanism
With the ideas for string processing from the previous section, we can proceed with the style development and design of our custom class.
3.1. Development and Design Approach
The style design references C++, where each line ends with ; to indicate the end of a statement, as shown below:
nu 0.01;Comment design references C++, with the following two forms:
// nu is viscosity
nu 0.01;
deltaT 0.005; // we can change deltaT
The error reporting design considers the following simple scenarios:
- The dictionary file does not exist or the file name is incorrect. The program should terminate and output the corresponding error message.
- The keyword in the dictionary cannot be found. The program should terminate and output the corresponding error message.
- The keyword exists in the dictionary but no value is assigned. The program should terminate and output the corresponding error message.
3.2. Development Improvements
The class declaration in IOdictionary.H has been further improved as follows:
| |
The class definition in IOdictionary.C has been improved as follows:
| |
The main source code remains unchanged.
3.3. Testing
Modify the local dictionary ofspProperties with the following content:
| |
Recompile, and readers can test various possible scenarios with the dictionary file. It can be observed that the results still meet the design requirements.
4. Summary
In the process of further developing features, we will realize that there are many data types that the reading operation needs to handle, especially OpenFOAM’s own types. Moreover, there are also many OpenFOAM input file formats and exception handling cases to address. These functional features undoubtedly require better program architecture and more program development.
The good news is that through our own development of input and output functionality, I believe readers now have a certain conceptual understanding of OpenFOAM’s dictionary files.
This section has completed the following discussions:
- Understanding the use of template classes
- Adding dictionary comments and error reporting mechanisms
- Compiling and running a feature project
Support us
Tip
Hopefully, the sharing here can be helpful to you.
If you find this content helpful, your comments or donations would be greatly appreciated. Your support helps ensure the ongoing updates, corrections, refinements, and improvements to this and future series, ultimately benefiting new readers as well.
The information and message provided during donation will be displayed as an acknowledgment of your support.
Copyright @ 2026 Aerosand
- Course (text, images, etc.):CC BY-NC-SA 4.0
- Code derived from OpenFOAM:GPL v3
- Other code:MIT License
