Ivan
Find attached set of modified suroutines and xml file in case of any error in it.
If you need any other info like mesh or eulerian checkpoint for restart, please let me know.
You will find easily the modified code. I have written the comment "mdt" in the modified areas or lines.
BR
Miguel
Adding new particle parameters
Re: Adding new particle parameters
- Attachments
-
- ivan20200501.zip
- (94.32 KiB) Downloaded 809 times
-
- Posts: 4125
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Adding new particle parameters
Hello,
You still did not indicate whether you tested on a debug build or under a debugger.
This would be well adapted to this type of bug,
I checked the sources briefly, but did not see anything obvious. Many of the diffs are just comments or whitespace (using Git, you can simply use "git diff" or gitk to know where you modified the code, so most "placeholder" comments only make things less readable). And everybody who does some sort of development with code_saturne should be using git. The time to learn the basics are much less than time wasted by not using it, so I assume you are using it.
In any case, "off by one" or subtle initialization errors are easier to spot with a debugger, or at least a debug build (and a backtrace, which appears in the error log for most common systems, at least when using gcc.).
Best regards,
Yvan
You still did not indicate whether you tested on a debug build or under a debugger.
This would be well adapted to this type of bug,
I checked the sources briefly, but did not see anything obvious. Many of the diffs are just comments or whitespace (using Git, you can simply use "git diff" or gitk to know where you modified the code, so most "placeholder" comments only make things less readable). And everybody who does some sort of development with code_saturne should be using git. The time to learn the basics are much less than time wasted by not using it, so I assume you are using it.
In any case, "off by one" or subtle initialization errors are easier to spot with a debugger, or at least a debug build (and a backtrace, which appears in the error log for most common systems, at least when using gcc.).
Best regards,
Yvan
Re: Adding new particle parameters
Hi Yvan,
This is just to tell you that, after some weeks, I have suceeded in getting good results with new variables in lagrangian module. In the meantime, I have jumped from version 5 to 6.
I have followed your instructions related to the compilation of headers in the main tree and others. I have found the code of version 6 a little bit changed from version 5, so this was a difficulty for me.
I have extended new parameters for refreshing the boundary face wall temperature after deposition due to thermal resistance.
In this case I have modified the function "_update_boundary_face_type" located in cs_lagr.c subroutine. This was for reading or getting the initial temperature of an impacted face, by introducing a new parameter in cs_lagr_zone_data_t structure. Originally, this function only got the type of BC zone (inlet, outlet, deposit1, fouling, etc) based on face_id. Now, it can get, in addition, the initial face temperature based on impacted face_id. It seems to work correctly. Do you think is this a suitable way to proceed? shall be stable?
Thank you for your help.
BR
Miguel
This is just to tell you that, after some weeks, I have suceeded in getting good results with new variables in lagrangian module. In the meantime, I have jumped from version 5 to 6.
I have followed your instructions related to the compilation of headers in the main tree and others. I have found the code of version 6 a little bit changed from version 5, so this was a difficulty for me.
I have extended new parameters for refreshing the boundary face wall temperature after deposition due to thermal resistance.
In this case I have modified the function "_update_boundary_face_type" located in cs_lagr.c subroutine. This was for reading or getting the initial temperature of an impacted face, by introducing a new parameter in cs_lagr_zone_data_t structure. Originally, this function only got the type of BC zone (inlet, outlet, deposit1, fouling, etc) based on face_id. Now, it can get, in addition, the initial face temperature based on impacted face_id. It seems to work correctly. Do you think is this a suitable way to proceed? shall be stable?
Thank you for your help.
BR
Miguel
-
- Posts: 4125
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Adding new particle parameters
Hello,
I do not know how your fouling model works, so it is hard to say whether your approach is good or not. If you are trying to keep track of particle impacts on a wall so as to adjust the wall temperature, I guess it could work, given a sufficiently long running time or a sufficient number of particles (so the statistics are converged).
If you just need the initial face temperature, it should work, but it assumes you already have a previous run without the model to obtain the local initial wall temperature (because if the value is uniform, you could simply set it as a model parameter, though automating it better such as you are doing avoids "forgetting" to adjust related parameters).
Best regards,
Yvan
I do not know how your fouling model works, so it is hard to say whether your approach is good or not. If you are trying to keep track of particle impacts on a wall so as to adjust the wall temperature, I guess it could work, given a sufficiently long running time or a sufficient number of particles (so the statistics are converged).
If you just need the initial face temperature, it should work, but it assumes you already have a previous run without the model to obtain the local initial wall temperature (because if the value is uniform, you could simply set it as a model parameter, though automating it better such as you are doing avoids "forgetting" to adjust related parameters).
Best regards,
Yvan