This issue is for adding fluid sources to the library.

@dhblum
One thing that I lost track of:
if we now copy models from IBPSA into IbpsaMpc manually, we will gradually diverge from IBPSA since new changes of IBPSA don't get merged into IbpsaMpc. To avoid this, it would make sense to set up some way to automate the merging process. Two problems here:

1. The buildingspy merger could be used for the merging, but it's not practical to use it for merging only a limited set of models (while it's easy to exclude a limit set of models). This functionality should thus be added to buildingspy. @mwetter do you agree?
2. The merging will overwrite our custom changes to the models that make them compatible with JModelica. One approach to reapply the changes is to use git cherry-pick, although I'm not sure whether this will work as intended, especially when merge conflicts arise. We would also have to keep track of all commits that modify IBPSA code.

Perhaps there is a better way but we better look into this before making too many PRs?

This issue is to create a unit testing framework that tests the compilation, simulation, and optimization of library models.

This issue is to add UserGuide.Acknowledgements similar to that found in https://github.com/ibpsa/modelica-ibpsa.

This issue is to add the MixingVolume model to the library.

I have completed (the first version of) the merge script. The merge script relies on the git patch functionality, which can generate merge conflicts to sort out conflicting edits. Furthermore, I prefer not to make automated git commits. Therefore, the merge process is now split up in two steps, which consists of multiple commits and two python calls to https://github.com/ibpsa/modelica-ibpsa-mpc/blob/issue1_sources_modifications/IbpsaMpc/Resources/Scripts/merge.py.

The following instructions are generated upon calling the merge script for the first time:

[parallels@localhost IbpsaMpc]$ python Resources/Scripts/merge.py 

The merge has been succesfully prepared. The following steps still have to be completed:
1) Commit the updated files that have been copied using:
> git commit -a -m "Merged files from the library IBPSA"
2) Run the merge script again, which updates .copiedFiles.txt, upon which the merge process continues. To abort, checkout all files.

and these the second time:

[parallels@localhost IbpsaMpc]$ python Resources/Scripts/merge.py 
The merge continues. The stored sha is 1b3b2a6e23d7de10cb62634a2dea57069cc74ab9. Next steps are:
3) Reapply earlier modifications using the patch file:
> git apply --3way merge.patch
4) Resolve conflicts if required, then also commit these changes, without amending:
> git commit -a

What happens in the back-end: the file .copiedFiles contains the sha of code before the previous patch was applied. When starting the script, a patch file is generated compared to this sha and stored to file (only for the files that are listed in the script), which effectively summarizes all changes compared to last merge. After that the file selection is copied from the IBPSA library using the normal merge scripts, which overwrites custom changes that may exist in these files. The file .copiedFiles is updated, but does not contain the new sha yet. This version of the code has to be committed for the patch process to work and the sha of that commit is also saved in.copiedFiles in phase 2 of the merge script. In phase 2, the sha is amended to .copiedFiles and further instructions are printed to apply the patch, which may or may not result in merge conflicts, which must then be resolved, then committed by the developer.

This works for the checkBoundary() removal (without merge conflict) but I'm sure that corner cases will pop up. @dhblum any feedback on this?