A maintenance release, v6.3.2, has been posted to correct a bug in the liquid evaporation routines. The bug should only affect v6.3.1.
FDS-SMV Downloads
Monday, December 7, 2015
Thursday, November 12, 2015
Uploading text files for Issues on GitHub
I recently got notification from GitHub support that they now allow Write access for uploading text files to Issues posts. This is welcome news.
Thanks to Dave McGill for testing this new feature.
This means that when you post an Issue you can attach your input file. But remember you need to append ".txt" to the file name. For example, if your input file is simple_test.fds, you need to change the name to simple_test.fds.txt or just simple_test.txt.
Thanks to Dave McGill for testing this new feature.
This means that when you post an Issue you can attach your input file. But remember you need to append ".txt" to the file name. For example, if your input file is simple_test.fds, you need to change the name to simple_test.fds.txt or just simple_test.txt.
Tuesday, November 10, 2015
FDS 6.3.1 Maintenance Release
Today we posted a maintenance release, FDS 6.3.1, bundled with Smokeview 6.3.2.
The main motivation for pushing out this release is to correct a bug in the mixing step for multi-step and finite-rate chemistry calculations. The default simple chemistry model is not affected.
An optional input parameter DT_HVAC has been added to help stabilize duct flow calculations.
Additionally, we have been working on testing FDS scaling on large compute clusters, like Titan at Oak Ridge National Laboratories. The results for weak and strong scaling on our burn cluster at NIST are published in the new user's guide and we have added an option to suppress output diagnostics, which slow the code for large jobs.
FDS-SMV website
FDS-SMV download page
Installation Instructions
FDS Release Notes
Smokeview Release Notes
The main motivation for pushing out this release is to correct a bug in the mixing step for multi-step and finite-rate chemistry calculations. The default simple chemistry model is not affected.
An optional input parameter DT_HVAC has been added to help stabilize duct flow calculations.
Additionally, we have been working on testing FDS scaling on large compute clusters, like Titan at Oak Ridge National Laboratories. The results for weak and strong scaling on our burn cluster at NIST are published in the new user's guide and we have added an option to suppress output diagnostics, which slow the code for large jobs.
FDS-SMV website
Installation Instructions
FDS Release Notes
Smokeview Release Notes
Thursday, November 5, 2015
CFAST 7 Released
Although this blog is intended primarily for news about FDS and Smokeview, we want to turn your attention for the moment to the zone model CFAST (Consolidated Fire And Smoke Transport). CFAST has been around since the late 1980s, and as the word "consolidated" implies, it was intended to unify into one code base various zone models that were developed at NIST and elsewhere in 1980s. It's been around for 25 years and has undergone 7 major revisions; the latest was released this week.
Many of you might be surprised to learn that CFAST is even still around. Why do we need CFAST when we have FDS? Doesn't FDS do everything that CFAST does, and more? Yes, it does, but FDS doesn't run in a second. Over the past decade, we've collaborated with the U.S. Department of Energy and the U.S. Nuclear Regulatory Commission, both of which still endorse the use of CFAST for its own inspectors and licensees in doing hazard analyses of high risk facilities. These analyses, or probabilistic risk assessments (PRAs), typically involve facilities with hundreds of compartments, many of which are simple and not heavily loaded with combustibles. CFAST is a great tool for doing "screening" analyses of these compartments. FDS is sometimes used in cases where the fire scenario does not conform to the basic assumptions of CFAST -- usually it is geometric complexity that demands CFD as opposed to a two-zone model.
Because we have a limited staff at NIST, we have tried to leverage all of the fire modeling expertise we have in maintaining CFAST. You will notice that the latest releases of FDS and CFAST are both installed in a folder called "firemodels" on a Windows PC. CFAST and FDS are in the same organization on GitHub, https://github.com/firemodels/, they use the same experiments for validation, they use the same basic installation process under Windows, and most importantly, they both use Smokeview.
CFAST 7 is a significant overhaul of the model, but not because we added new features. In fact, we removed many features, streamlined the source code and documentation, and improved (hopefully) the graphical user interface. We did this because we realized that CFAST was too bloated with unvalidated, undocumented, untested, and unnecessary features that detracted from its real value of being a simple, robust compartment fire model. How did this happen? Easy -- and it should be seen as a cautionary tale to anyone who wants to develop a new fire model. If you take a look at a survey conducted by the engineering firm Combustion Science and Engineering,
http://www.firemodelsurvey.com/ZoneModels.html
you'll notice that there have been over 50 zone models developed in the past 3 decades, but only 3 (in the survey anyway) are still under some kind of maintenance. The rest -- who knows? We suspect, based on our own experience, is that developing a zone model is fairly easy, but maintaining it is hard. We spend more time doing routine maintenance work for FDS than we spend developing new features. CFAST is certainly not as complex as FDS, but it still requires good documentation, a usable interface, verification and validation, and compatibility with evolving computer operating systesm. The team that developed CFAST has dwindled down to a few people, principally Rick Peacock, and its long term prospects are uncertain. At the very least, the latest overhaul of CFAST has put it in a better place with respect to long term maintenance, but no matter how good our current practices are, no model can sustain itself on auto-pilot. Those 50 plus zone models have essentially rotted -- even if one is able to recompile and run them, they would not pass a thorough quality review that we expect of fire models these days. These old codes were basically academic exercises developed by individuals or organizations who had no particular long term plan for them.
In the next few months, we're hoping to do some kind of survey to assess who is using CFAST so that we can plan for the future. Your input will be critical. There is no point in expending scarce resources on a model that is not used. We hope, however, that if you take a look at the new CFAST you will find that it still has a role to play in fire protection engineering. Don't be shy with your feedback. If something doesn't work, or even if something seems more difficult than it should be, let us know. CFAST uses GoogleGroups for general discussion:
https://groups.google.com/forum/#!forum/cfast
and GitHub for specific Issue Tracking:
https://github.com/firemodels/cfast/issues
Many of you might be surprised to learn that CFAST is even still around. Why do we need CFAST when we have FDS? Doesn't FDS do everything that CFAST does, and more? Yes, it does, but FDS doesn't run in a second. Over the past decade, we've collaborated with the U.S. Department of Energy and the U.S. Nuclear Regulatory Commission, both of which still endorse the use of CFAST for its own inspectors and licensees in doing hazard analyses of high risk facilities. These analyses, or probabilistic risk assessments (PRAs), typically involve facilities with hundreds of compartments, many of which are simple and not heavily loaded with combustibles. CFAST is a great tool for doing "screening" analyses of these compartments. FDS is sometimes used in cases where the fire scenario does not conform to the basic assumptions of CFAST -- usually it is geometric complexity that demands CFD as opposed to a two-zone model.
Because we have a limited staff at NIST, we have tried to leverage all of the fire modeling expertise we have in maintaining CFAST. You will notice that the latest releases of FDS and CFAST are both installed in a folder called "firemodels" on a Windows PC. CFAST and FDS are in the same organization on GitHub, https://github.com/firemodels/, they use the same experiments for validation, they use the same basic installation process under Windows, and most importantly, they both use Smokeview.
CFAST 7 is a significant overhaul of the model, but not because we added new features. In fact, we removed many features, streamlined the source code and documentation, and improved (hopefully) the graphical user interface. We did this because we realized that CFAST was too bloated with unvalidated, undocumented, untested, and unnecessary features that detracted from its real value of being a simple, robust compartment fire model. How did this happen? Easy -- and it should be seen as a cautionary tale to anyone who wants to develop a new fire model. If you take a look at a survey conducted by the engineering firm Combustion Science and Engineering,
http://www.firemodelsurvey.com/ZoneModels.html
you'll notice that there have been over 50 zone models developed in the past 3 decades, but only 3 (in the survey anyway) are still under some kind of maintenance. The rest -- who knows? We suspect, based on our own experience, is that developing a zone model is fairly easy, but maintaining it is hard. We spend more time doing routine maintenance work for FDS than we spend developing new features. CFAST is certainly not as complex as FDS, but it still requires good documentation, a usable interface, verification and validation, and compatibility with evolving computer operating systesm. The team that developed CFAST has dwindled down to a few people, principally Rick Peacock, and its long term prospects are uncertain. At the very least, the latest overhaul of CFAST has put it in a better place with respect to long term maintenance, but no matter how good our current practices are, no model can sustain itself on auto-pilot. Those 50 plus zone models have essentially rotted -- even if one is able to recompile and run them, they would not pass a thorough quality review that we expect of fire models these days. These old codes were basically academic exercises developed by individuals or organizations who had no particular long term plan for them.
In the next few months, we're hoping to do some kind of survey to assess who is using CFAST so that we can plan for the future. Your input will be critical. There is no point in expending scarce resources on a model that is not used. We hope, however, that if you take a look at the new CFAST you will find that it still has a role to play in fire protection engineering. Don't be shy with your feedback. If something doesn't work, or even if something seems more difficult than it should be, let us know. CFAST uses GoogleGroups for general discussion:
https://groups.google.com/forum/#!forum/cfast
and GitHub for specific Issue Tracking:
https://github.com/firemodels/cfast/issues
Friday, October 9, 2015
Some Recent FDS Validation Exercises
With the release of FDS 6.3, we'd like to take this opportunity to point out a few notable FDS validation cases that have been added to the FDS Validation Guide.
NRCC Smoke Tower Experiments
About 10 years ago, researchers at the National Research Council Canada conducted fire experiments in a 10 story tower that was specially designed to study fire and smoke movement in a high rise building. The experiments and subsequent FDS simulations are described in the following papers:
Y. Wang, E. Zalok, and G. Hadjisophocleous. An Experimental Study of Smoke Movement in Multi-Storey Buildings. Fire Technology, 47:1141–1169, 2011.
G. Hadjisophocleous and Q. Jia. Comparison of FDS Prediction of Smoke Movement in a 10-Storey Building with Experimental Data. Fire Technology, 45:163–177, 2009.
However, the FDS simulations were done with FDS 4 and up until now there has been no mention of these experiments in the FDS Validation Guide. So, if you wanted to cite these papers as evidence that FDS is an appropriate model for this kind of fire scenario, you would probably be challenged because FDS 4 was last released in 2005, about the same time the experiments were performed. Thankfully, Paul Tyson, a student at Ulster University (formerly the U. of Ulster), re-analyzed the experimental data and performed simulations with the latest version of FDS. He then worked with us to get these simulations permanently archived in the FDS Validation Guide. This was not an easy job. Paul had to dig up old plans of the building, talk to the various researchers involved, weed through the various experimental data sets, and then figure out how to use the new ventilation features in FDS to model the leakage in the building. In the end, Paul found that leakage was a significant factor in the modeling, but this information was not well-quantified in the existing documentation.
PRISME DOOR Experiments
PRISME is the name of a fire test program conducted under the auspices of the Organization for Economic Cooperation and Development, Nuclear Energy Agency (OECD/NEA). The experiments were conducted at the French Institut de radioprotection et de sûreté nucléaire (IRSN) at Cadarache. A variety of experiments were conducted to study ventilation effects, electrical cable failure, and leakage. The test reports are not publicly available, but an entire edition of Fire Safety Journal documented various experimental and modeling studies. Two notable papers are:
L. Audouin, L. Rigollet, H. Prétrel,W. LeSaux, and M. Röwekamp. OECD PRISME project: Fires in confined and ventilated nuclear-type multi-compartments–Overview and main experimental results. Fire Safety Journal, 62:80–101, 2013.
J.Wahlqvist and P. van Hees. Validation of FDS for large-scale well-confined mechanically ventilated fire scenarios with emphasis on predicting ventilation system behavior. Fire Safety Journal, 62:102– 114, 2013.
As with the NRCC experiments, the FDS simulations were not added to the FDS Validation Guide until recently, for various reasons. We would like to give thanks to Jonathan Wahlqvist of Lund University, who analyzed the HVAC system of the test facility using FDS. He provided us his FDS input files and now these calculations are permanently archived in the FDS Validation Guide. These experiments and simulations demonstrate that the HVAC functionality in FDS that was added by Jason Floyd over the past decade works quite well. Thanks to Jonathan for his perseverance in setting up the fairly complex series of ducts, nodes, and fans.
What you can do to help
Even with the help of students, it is a tremendous amount of work to add a new data set to the FDS Validation Guide. In our experience, fire experiments are typically documented in a variety of test reports, student theses, papers, and conference proceedings. Rarely is there a single comprehensive test report and electronic file containing the data in an easy to understand format. So if you are now performing validation simulations using FDS or considering it, please contact us as soon as possible. Waiting until your thesis is done or your paper published is usually too late -- we need to work with you now so that when you are done the input files, data sets, and documentation will be in a form that is easy for us to incorporate into our Validation Guide. The final paper or thesis is rarely good enough -- there is always information that falls between the cracks.
The value added in contacting us early is that we have developed a fairly elaborate set of scripts to analyze and compare experimental data and FDS simulations. We would want to get your data and results into this system early so that both you and the rest of the community can benefit from the added set of validation.
NRCC Smoke Tower Experiments
About 10 years ago, researchers at the National Research Council Canada conducted fire experiments in a 10 story tower that was specially designed to study fire and smoke movement in a high rise building. The experiments and subsequent FDS simulations are described in the following papers:
Y. Wang, E. Zalok, and G. Hadjisophocleous. An Experimental Study of Smoke Movement in Multi-Storey Buildings. Fire Technology, 47:1141–1169, 2011.
G. Hadjisophocleous and Q. Jia. Comparison of FDS Prediction of Smoke Movement in a 10-Storey Building with Experimental Data. Fire Technology, 45:163–177, 2009.
However, the FDS simulations were done with FDS 4 and up until now there has been no mention of these experiments in the FDS Validation Guide. So, if you wanted to cite these papers as evidence that FDS is an appropriate model for this kind of fire scenario, you would probably be challenged because FDS 4 was last released in 2005, about the same time the experiments were performed. Thankfully, Paul Tyson, a student at Ulster University (formerly the U. of Ulster), re-analyzed the experimental data and performed simulations with the latest version of FDS. He then worked with us to get these simulations permanently archived in the FDS Validation Guide. This was not an easy job. Paul had to dig up old plans of the building, talk to the various researchers involved, weed through the various experimental data sets, and then figure out how to use the new ventilation features in FDS to model the leakage in the building. In the end, Paul found that leakage was a significant factor in the modeling, but this information was not well-quantified in the existing documentation.
PRISME DOOR Experiments
PRISME is the name of a fire test program conducted under the auspices of the Organization for Economic Cooperation and Development, Nuclear Energy Agency (OECD/NEA). The experiments were conducted at the French Institut de radioprotection et de sûreté nucléaire (IRSN) at Cadarache. A variety of experiments were conducted to study ventilation effects, electrical cable failure, and leakage. The test reports are not publicly available, but an entire edition of Fire Safety Journal documented various experimental and modeling studies. Two notable papers are:
L. Audouin, L. Rigollet, H. Prétrel,W. LeSaux, and M. Röwekamp. OECD PRISME project: Fires in confined and ventilated nuclear-type multi-compartments–Overview and main experimental results. Fire Safety Journal, 62:80–101, 2013.
J.Wahlqvist and P. van Hees. Validation of FDS for large-scale well-confined mechanically ventilated fire scenarios with emphasis on predicting ventilation system behavior. Fire Safety Journal, 62:102– 114, 2013.
As with the NRCC experiments, the FDS simulations were not added to the FDS Validation Guide until recently, for various reasons. We would like to give thanks to Jonathan Wahlqvist of Lund University, who analyzed the HVAC system of the test facility using FDS. He provided us his FDS input files and now these calculations are permanently archived in the FDS Validation Guide. These experiments and simulations demonstrate that the HVAC functionality in FDS that was added by Jason Floyd over the past decade works quite well. Thanks to Jonathan for his perseverance in setting up the fairly complex series of ducts, nodes, and fans.
What you can do to help
Even with the help of students, it is a tremendous amount of work to add a new data set to the FDS Validation Guide. In our experience, fire experiments are typically documented in a variety of test reports, student theses, papers, and conference proceedings. Rarely is there a single comprehensive test report and electronic file containing the data in an easy to understand format. So if you are now performing validation simulations using FDS or considering it, please contact us as soon as possible. Waiting until your thesis is done or your paper published is usually too late -- we need to work with you now so that when you are done the input files, data sets, and documentation will be in a form that is easy for us to incorporate into our Validation Guide. The final paper or thesis is rarely good enough -- there is always information that falls between the cracks.
The value added in contacting us early is that we have developed a fairly elaborate set of scripts to analyze and compare experimental data and FDS simulations. We would want to get your data and results into this system early so that both you and the rest of the community can benefit from the added set of validation.
Tuesday, October 6, 2015
Realizability paper accepted
Issue 2261 posted by Dan Swenson of Thunderhead Engineering led to a revamp of the species transport scheme to guarantee realizable mass fractions. These changes were incorporated into FDS 6.2.0. The approach we developed has a few novel aspects and so Jason Floyd and I submitted the work for publication in Fire Safety Journal. Today we got word that the final version has been posted online and may be viewed here.
Thursday, October 1, 2015
FDS-SMV 6.3.0 Release
Today we posted a new minor release of FDS and Smokeview, version 6.3.0. Please visit the downloads page on the FDS-SMV website to download the bundle for your platform.
The changes made to FDS are in some ways quite minor and likely will not affect most users. The two most important changes are (1) the heat release rate limiter has been removed from the combustion model and (2) new default values of radiative fraction have been assigned to select fuels (such as methane, which has a radiative fraction of approximately 0.2; a complete list is given in the FDS User Guide).
We have also implemented a multi-fuel model for the radiative fraction where we weight the local value by the reaction rate for each fuel. Because of this change, the RADIATIVE_FRACTION input parameter has been moved from the RADI line to the REAC line. This should be the only input parameter change required for this new version.
We realize there has been a lot of chatter on the discussion forum recently about running MPI on Windows machines. Unfortunately, we have not been able to simplify this process as of yet. Our best advice is contained in the wiki Running FDS MPI on Windows. Please let us know as soon as possible if you run into trouble with this latest release. Issues may be submitted here.
GitHub pull requests are welcome!
This is the first release since our migration from Google Code to GitHub. We have, I believe, managed to maintain a balance between the stability of our old Subversion workflow and the flexibility and power of a distributed Git workflow. We have basically adopted what Atlassian refers to as the Forking Workflow [insert bad joke here]. Each project member "forks" the repository and sends pull requests to the project maintainer. What this means is that YOUR workflow and MY workflow for FDS development are nearly identical---the only difference is that I can accept pull requests. We hope this will take collaboration to a new level.
If you are new to Git, the following link may be helpful:
FDS-SMV Git User Workflow
What's on the horizon?
The migration from Google Code to GitHub was a fairly heavy lift. But with this minor release we hope to be in a position in the coming year to focus on development of chemistry, complex geometry, and scalability for multi-mesh calculations.
Please continue to monitor progress on Issues you care about and present enhancement requests for features you feel would be helpful.
The changes made to FDS are in some ways quite minor and likely will not affect most users. The two most important changes are (1) the heat release rate limiter has been removed from the combustion model and (2) new default values of radiative fraction have been assigned to select fuels (such as methane, which has a radiative fraction of approximately 0.2; a complete list is given in the FDS User Guide).
We have also implemented a multi-fuel model for the radiative fraction where we weight the local value by the reaction rate for each fuel. Because of this change, the RADIATIVE_FRACTION input parameter has been moved from the RADI line to the REAC line. This should be the only input parameter change required for this new version.
We realize there has been a lot of chatter on the discussion forum recently about running MPI on Windows machines. Unfortunately, we have not been able to simplify this process as of yet. Our best advice is contained in the wiki Running FDS MPI on Windows. Please let us know as soon as possible if you run into trouble with this latest release. Issues may be submitted here.
GitHub pull requests are welcome!
This is the first release since our migration from Google Code to GitHub. We have, I believe, managed to maintain a balance between the stability of our old Subversion workflow and the flexibility and power of a distributed Git workflow. We have basically adopted what Atlassian refers to as the Forking Workflow [insert bad joke here]. Each project member "forks" the repository and sends pull requests to the project maintainer. What this means is that YOUR workflow and MY workflow for FDS development are nearly identical---the only difference is that I can accept pull requests. We hope this will take collaboration to a new level.
If you are new to Git, the following link may be helpful:
FDS-SMV Git User Workflow
What's on the horizon?
The migration from Google Code to GitHub was a fairly heavy lift. But with this minor release we hope to be in a position in the coming year to focus on development of chemistry, complex geometry, and scalability for multi-mesh calculations.
Please continue to monitor progress on Issues you care about and present enhancement requests for features you feel would be helpful.
Monday, June 29, 2015
FDS-SMV has moved to GitHub
Dear Users,
As of today, the FDS-SMV code project is officially on GitHub.
The project GitHub site is
https://github.com/firemodels/fds-smv
The new website URL is
http://firemodels.github.io/fds-smv
Please note that the Issue Tracker has moved to
https://github.com/firemodels/fds-smv/issues
The migration of issues was not a seamless process. A couple of things happened: The issue numbers got out of sync and a few of the issues were dropped. So, if you have an open issue you have been monitoring, please go to the issues site and locate it. You cannot find it, please post a new issue.
We are hopeful that Git will fulfill its promise of easing collaboration for a large, open-source project. We've outlined a suggested workflow here:
https://github.com/firemodels/fds-smv/wiki/Git-User-Workflow
Let us know if there are any problems with the website links or downloads. We look forward to your contribution and feedback.
Cheers,
The FDS-SMV Development Team
As of today, the FDS-SMV code project is officially on GitHub.
The project GitHub site is
https://github.com/firemodels/fds-smv
The new website URL is
http://firemodels.github.io/fds-smv
Please note that the Issue Tracker has moved to
https://github.com/firemodels/fds-smv/issues
The migration of issues was not a seamless process. A couple of things happened: The issue numbers got out of sync and a few of the issues were dropped. So, if you have an open issue you have been monitoring, please go to the issues site and locate it. You cannot find it, please post a new issue.
We are hopeful that Git will fulfill its promise of easing collaboration for a large, open-source project. We've outlined a suggested workflow here:
https://github.com/firemodels/fds-smv/wiki/Git-User-Workflow
Let us know if there are any problems with the website links or downloads. We look forward to your contribution and feedback.
Cheers,
The FDS-SMV Development Team
Tuesday, June 23, 2015
Please Postpone Issue Submission for GitHub Migration
Next week we will be migrating the FDS-SMV project from Google Code to GitHub. There will be more to say about this transition over the coming days and weeks. For the time being, please postpone submitting any new Issues or commenting on active Issues for roughly the next three days while we migrate the Issues over to GitHub. Thank you for your understanding.
Plans are for the GitHub site to go live on Monday. Stay tuned...
Plans are for the GitHub site to go live on Monday. Stay tuned...
Monday, April 13, 2015
FDS 6.2.0 released
We just posted a release of FDS 6.2.0. This is a minor release, meaning that you can expect to see some changes in model results due to minor changes in various algorithms. We would urge you to finish out existing projects or studies with your current version and then upgrade to 6.2 as soon as you can. The reason why is that when bugs are reported for older versions, there is nothing we can do until the bug is observed in the latest version.
A significant change in this release is that there is now only one FDS executable for each of the three operating systems we support, Windows, Linux, and Mac OS X. Thus if you type "fds" or the old "fds_mpi", you will be issuing the same command. OpenMP and MPI are built in to this single executable and we urge you to take a look at the FDS User's Guide chapter called "Running FDS". There has been considerable confusion about OpenMP and MPI, and hopefully this new chapter will help clear some of it up. FDS still works like it always has from the command line if you just type
fds job_name.fds
but there are now a number of options you have to make the job run faster.
One other thing to note is that in the Windows release, we have switched from an older MPI scheduler to the one that is currently maintained by Intel. That is, when you run an MPI calculation by issuing the mpiexec command, you are using a newer version of the scheduler called "hydra_service". Those of you who are curious what this is, just do an Internet search. You should not notice a change in functionality from what we were doing in the last release, 6.1.2; it's just that a different background process will be running. Let us know as soon as possible if you notice anything different about the MPI on Windows.
A significant change in this release is that there is now only one FDS executable for each of the three operating systems we support, Windows, Linux, and Mac OS X. Thus if you type "fds" or the old "fds_mpi", you will be issuing the same command. OpenMP and MPI are built in to this single executable and we urge you to take a look at the FDS User's Guide chapter called "Running FDS". There has been considerable confusion about OpenMP and MPI, and hopefully this new chapter will help clear some of it up. FDS still works like it always has from the command line if you just type
fds job_name.fds
but there are now a number of options you have to make the job run faster.
One other thing to note is that in the Windows release, we have switched from an older MPI scheduler to the one that is currently maintained by Intel. That is, when you run an MPI calculation by issuing the mpiexec command, you are using a newer version of the scheduler called "hydra_service". Those of you who are curious what this is, just do an Internet search. You should not notice a change in functionality from what we were doing in the last release, 6.1.2; it's just that a different background process will be running. Let us know as soon as possible if you notice anything different about the MPI on Windows.
Subscribe to:
Posts (Atom)
