https://wikis.ch.cam.ac.uk/thom/wiki/api.php?action=feedcontributions&feedformat=atom&user=Tkl35 Thom Group Wiki - User contributions [en] 2026-06-10T15:40:20Z User contributions MediaWiki 1.39.7 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=The_Ten_Git-mmandments&diff=1027 The Ten Git-mmandments 2022-08-25T14:23:30Z <p>Tkl35: </p> <hr /> <div>Herein lies precious Git-related wisdom, do not disregard at your own convenience!<br /> <br /> #'''Do NOT treat Git repositories like Google Drive'''.<br /> #*Git repositories do not exist for you to backup all your files (e.g., cache, output and log files).<br /> #*Do not be trigger happy with ```git add --all```.<br /> #*Do not add whole directories.<br /> #*Maintain a minimalistic mentality, i.e., carefully consider what files are important with the focus on successfully allowing the user to run your code.<br /> #'''Do NOT include .pyc files, the entire __pycache__ folder and .DS_Store files.'''<br /> #*Basically, you have been warned.<br /> #'''Do NOT ignore .gitignore.'''<br /> #*They do not exist for no reason, create one to satisfy the above rules.<br /> #*Visit https://git-scm.com/docs/gitignore for more information on formatting one.<br /> #*Do not skip the following (bad) example:<br /> #::&gt; Sometimes, you might want to code using an IDE on your personal computer, git push and then git pull onto a workstation to run the code. <br /> #::&gt; As expected, you run into an error, nano into the file with the error and make the necessary changes.<br /> #::&gt; The code now works and you happily git push from the workstation, with all your output and cached folders.<br /> #'''Do NOT send a merge request with over 453 changed files - this is impossible to review!'''<br /> #*Do not operate with the mentality of only submitting completed working code.<br /> #*Do not forget that little and often with code review is better than the former.<br /> #*Besides the mundane rationale of catching your mistakes and getting feedback quicker rather than letting than accumulate, it allows the reviewer to better track and follow your changes.<br /> #'''Do NOT forget the concept and importance of source control.'''<br /> #*This is a big one. Basically, when you are coding as a team, or if your work is derived from another user, or needs to be passed on to future users, you must consider code maintenance and management.<br /> #*For example, as much as possible, do not explicitly include other people's code in your own repository, because when they update their code, you do not want to repeat the cloning or downloading process again, or have to sieve through all your and their code to find what has changed and needs to be updated. What you do want is to simply perform a ```git pull```. To that end, do not forget git submodules exist for a very good reason. See https://git-scm.com/book/en/v2/Git-Tools-Submodules.<br /> #*Along those lines, you also do not want to edit someone else's code as much as possible.<br /> #::&gt; For example, say you import the python package phreeqpy that serves as a wrapper for phreeqc, which is a piece of software written in C that you wish to use.<br /> #::&gt; You quickly realise one of the files, ```phreeqpy_dll.py``` is causing errors, and needs to be modified to suit your needs.<br /> #::&gt; You might wonder &quot;Wouldn't the easiest solution be to make a new repository for phreeqpy, replace the _dll file with a newly edited (by you) _dll2 file and adding it as a submodule (*gasps* something about explicitly including someone else's code)? Clearly, the _dll2 file contains everything required to perform the job!&quot;<br /> #::&gt; However, what you do not realise is that making a new repository means having to deal with the compilation of phreeqc underneath it (which is the job of phreeqpy), which will result in more work further down the road because you have effectively, albeit inadvertently, involved yourself in managing phreeqpy, and all the hard work required to make it interface with phreeqc, which is not your job.<br /> #::&gt; Indeed, do not rule out the possibility that it will probably be much less painful to make a single wrapper _dll2 file, and have '''your''' own module in '''your''' own repository import whatever is needed from the original '''unedited''' _dll file and extend its function by also importing '''your''' _dll2 file.<br /> #::&gt; This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.<br /> #*As a maxim, you do not ever want to add a file to a repository that you did not create.<br /> #'''Do NOT think once when having to modify someone else's code.'''<br /> #*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.<br /> #*Moving on, what you can do here is:<br /> #::&gt; Create a new repository separate from your '''present repository'''.<br /> #::&gt; Branch the (target) person's project into your new repository. The term for such a &quot;cross-repository&quot; branch is fork.<br /> #::&gt; Inside your new repository, make a '''new branch''' where you make your modifications to their code as git commits with a merge request back into the ```main``` (of your new repository) at the end.<br /> #::&gt; If you are in the mood, you can even make a ```pull request``` back to the (target) person's project branch with your new code.<br /> #::&gt; But considering your own needs first, you can then add this '''new branch''' as a submodule in your '''present repository'''.<br /> #::&gt; Again, do not forget that untangling other people's code is a horrible process, so you want to keep yours and their code as separate as possible.<br /> #'''Do NOT include autogenerated files in your git repository.'''<br /> #*Do not forget that autogenerated files, e.g., .o and .d files, will change when you recompile them even if their source files have not.<br /> #*Instead, add the compilation instructions to your README and leave that to the user. Again, do not forget ```make``` files exist.<br /> #'''Do NOT forget to test your code on a workstation.'''<br /> #*It is not a matter of making sure your code runs on a specific workstation, but to remember that the end user will have a different machine with a different setup.<br /> #*For example, your code may require a compiler GLIBC &gt;= 2.29 that in turn requires Ubuntu &gt;=20.04. A quick check will reveal, as of August 2022, that most machines are running an older version.<br /> #*Therefore, do not forget to include a detailed list of instructions and system requirements when asking someone else to review your code.<br /> #*You do not want your reviewer (and therefore you) to spend ages just to debug software requirement related errors.<br /> #*As such, do not miss an opportunity to test your code on a 'fresh' machine. It may be helpful to even record the system specifications when your code runs successfully to aid with that.<br /> #'''Do NOT be afraid to clarify git related concepts as early as possible.'''<br /> #*Especially when it is your first time using Git.<br /> #'''Do NOT forget to share your mistakes and helpful pointers with your colleagues.'''<br /> #*We certainly do not wish to entertain the situation of multiple people making the same mistakes with the same reviewer.<br /> <br /> &quot;Do not&quot; counter: 37</div> Tkl35 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=The_Ten_Git-mmandments&diff=1026 The Ten Git-mmandments 2022-08-25T14:14:39Z <p>Tkl35: </p> <hr /> <div>Herein lies precious Git-related wisdom, do not disregard at your own convenience!<br /> <br /> #'''Do NOT treat Git repositories like Google Drive'''.<br /> #*Git repositories do not exist for you to backup all your files (e.g., cache, output and log files).<br /> #*Do not be trigger happy with ```git add --all```.<br /> #*Do not add whole directories.<br /> #*Maintain a minimalistic mentality, i.e., carefully consider what files are important with the focus on successfully allowing the user to run your code.<br /> #'''Do NOT include .pyc files, the entire __pycache__ folder and .DS_Store files.'''<br /> #*Basically, you have been warned.<br /> #'''Do NOT ignore .gitignore.'''<br /> #*They do not exist for no reason, create one to satisfy the above rules.<br /> #*Visit https://git-scm.com/docs/gitignore for more information on formatting one.<br /> #*Do not skip the following example:<br /> #::&gt; Sometimes, you might want to code using an IDE on your personal computer, git push and then git pull onto a workstation to run the code. <br /> #::&gt; As expected, you run into an error, nano into the file with the error and make the necessary changes.<br /> #::&gt; The code now works and you happily git push from the workstation, with all your output and cached folders.<br /> #'''Do NOT send a merge request with over 453 changed files - this is impossible to review!'''<br /> #*Do not operate with the mentality of only submitting completed working code.<br /> #*Do not forget that little and often with code review is better than the former.<br /> #*Besides the mundane rationale of catching your mistakes and getting feedback quicker rather than letting than accumulate, it allows the reviewer to better track and follow your changes.<br /> #'''Do NOT forget the concept and importance of source control.'''<br /> #*This is a big one. Basically, when you are coding as a team, or if your work is derived from another user, or needs to be passed on to future users, you must consider code maintenance and management.<br /> #*For example, as much as possible, do not explicitly include other people's code in your own repository, because when they update their code, you do not want to repeat the cloning or downloading process again, or have to sieve through all your and their code to find what has changed and needs to be updated. What you do want is to simply perform a ```git pull```. To that end, do not forget git submodules exist for a very good reason. See https://git-scm.com/book/en/v2/Git-Tools-Submodules.<br /> #*Along those lines, you also do not want to edit someone else's code as much as possible.<br /> #::&gt; For example, say you import the python package phreeqpy that serves as a wrapper for phreeqc, which is a piece of software written in C that you wish to use.<br /> #::&gt; You quickly realise one of the files, ```phreeqpy_dll.py``` is causing errors, and needs to be modified to suit your needs.<br /> #::&gt; You might wonder &quot;Wouldn't the easiest solution be to make a new repository for phreeqpy, replace the _dll file with a newly edited (by you) _dll2 file and adding it as a submodule (*gasps* something about explicitly including someone else's code)? Clearly, the _dll2 file contains everything required to perform the job!&quot;<br /> #::&gt; However, what you do not realise is that making a new repository means having to deal with the compilation of phreeqc underneath it (which is the job of phreeqpy), which will result in more work further down the road because you have effectively, albeit inadvertently, involved yourself in managing phreeqpy, and all the hard work required to make it interface with phreeqc, which is not your job.<br /> #::&gt; Indeed, do not rule out the possibility that it will probably be much less painful to make a single wrapper _dll2 file, and have '''your''' own module in '''your''' own repository import whatever is needed from the original '''unedited''' _dll file and extend its function by also importing '''your''' _dll2 file.<br /> #::&gt; This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.<br /> #*As a maxim, you do not ever want to add a file to a repository that you did not create.<br /> #'''Do NOT think once when having to modify someone else's code.'''<br /> #*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.<br /> #*Moving on, what you can do here is:<br /> #::&gt; Create a new repository separate from your '''present repository'''.<br /> #::&gt; Branch the (target) person's project into your new repository. The term for such a &quot;cross-repository&quot; branch is fork.<br /> #::&gt; Inside your new repository, make a '''new branch''' where you make your modifications to their code as git commits with a merge request back into the ```main``` (of your new repository) at the end.<br /> #::&gt; If you are in the mood, you can even make a ```pull request``` back to the (target) person's project branch with your new code.<br /> #::&gt; But considering your own needs first, you can then add this '''new branch''' as a submodule in your '''present repository'''.<br /> #::&gt; Again, do not forget that untangling other people's code is a horrible process, so you want to keep yours and their code as separate as possible.<br /> #'''Do NOT include autogenerated files in your git repository.'''<br /> #*Do not forget that autogenerated files, e.g., .o and .d files, will change when you recompile them even if their source files have not.<br /> #*Instead, add the compilation instructions to your README and leave that to the user. Again, do not forget ```make``` files exist.<br /> #'''Do NOT forget to test your code on a workstation.'''<br /> #*It is not a matter of making sure your code runs on a specific workstation, but to remember that the end user will have a different machine with a different setup.<br /> #*For example, your code may require a compiler GLIBC &gt;= 2.29 that in turn requires Ubuntu &gt;=20.04. A quick check will reveal, as of August 2022, that most machines are running an older version.<br /> #*Therefore, do not forget to include a detailed list of instructions and system requirements when asking someone else to review your code.<br /> #*You do not want your reviewer (and therefore you) to spend ages just to debug software requirement related errors.<br /> #*As such, do not miss an opportunity to test your code on a 'fresh' machine. It may be helpful to even record the system specifications when your code runs successfully to aid with that.<br /> #'''Do NOT be afraid to clarify git related concepts as early as possible.'''<br /> #*Especially when it is your first time using Git.<br /> #'''Do NOT forget to share your mistakes and helpful pointers with your colleagues.'''<br /> #*We certainly do not wish to entertain the situation of multiple people making the same mistakes with the same reviewer.<br /> <br /> &quot;Do not&quot; counter: 37</div> Tkl35 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=The_Ten_Git-mmandments&diff=1025 The Ten Git-mmandments 2022-08-25T14:14:27Z <p>Tkl35: </p> <hr /> <div>Herein lies precious Git-related wisdom, do not disregard at your own convenience!<br /> <br /> #'''Do NOT treat Git repositories like Google Drive'''.<br /> #*Git repositories do not exist for you to backup all your files (e.g., cache, output and log files).<br /> #*Do not be trigger happy with ```git add --all```.<br /> #*Do not add whole directories.<br /> #*Maintain a minimalistic mentality, i.e., carefully consider what files are important with the focus on successfully allowing the user to run your code.<br /> #'''Do NOT include .pyc files, the entire __pycache__ folder and .DS_Store files.'''<br /> #*Basically, you have been warned.<br /> #'''Do NOT ignore .gitignore.'''<br /> #*They do not exist for no reason, create one to satisfy the above rules.<br /> #*Visit https://git-scm.com/docs/gitignore for more information on formatting one.<br /> #*Do not skip the following example:<br /> #::&gt; Sometimes, you might want to code using an IDE on your personal computer, git push and then git pull onto a workstation to run the code. <br /> #::&gt; As expected, you run into an error, nano into the file with the error and make the necessary changes.<br /> #::&gt; The code now works and you happily git push from the workstation, with all your output and cached folders.<br /> #'''Do NOT send a merge request with over 453 changed files - this is impossible to review!'''<br /> #*Do not operate with the mentality of only submitting completed working code.<br /> #*Do not forget that little and often with code review is better than the former.<br /> #*Besides the mundane rationale of catching your mistakes and getting feedback quicker rather than letting than accumulate, it allows the reviewer to better track and follow your changes.<br /> #'''Do NOT forget the concept and importance of source control.'''<br /> #*This is a big one. Basically, when you are coding as a team, or if your work is derived from another user, or needs to be passed on to future users, you must consider code maintenance and management.<br /> #*For example, as much as possible, do not explicitly include other people's code in your own repository, because when they update their code, you do not want to repeat the cloning or downloading process again, or have to sieve through all your and their code to find what has changed and needs to be updated. What you do want is to simply perform a ```git pull```. To that end, do not forget git submodules exist for a very good reason. See https://git-scm.com/book/en/v2/Git-Tools-Submodules.<br /> #*Along those lines, you also do not want to edit someone else's code as much as possible.<br /> #::&gt; For example, say you import the python package phreeqpy that serves as a wrapper for phreeqc, which is a piece of software written in C that you wish to use.<br /> #::&gt; You quickly realise one of the files, ```phreeqpy_dll.py``` is causing errors, and needs to be modified to suit your needs.<br /> #::&gt; You might wonder &quot;Wouldn't the easiest solution be to make a new repository for phreeqpy, replace the _dll file with a newly edited (by you) _dll2 file and adding it as a submodule (*gasps* something about explicitly including someone else's code)? Clearly, the _dll2 file contains everything required to perform the job!&quot;<br /> #::&gt; However, what you do not realise is that making a new repository means having to deal with the compilation of phreeqc underneath it (which is the job of phreeqpy), which will result in more work further down the road because you have effectively, albeit inadvertently, involved yourself in managing phreeqpy, and all the hard work required to make it interface with phreeqc, which is not your job.<br /> #::&gt; Indeed, do not rule out the possibility that it will probably be much less painful to make a single wrapper _dll2 file, and have '''your''' own module in '''your''' own repository import whatever is needed from the original '''unedited''' _dll file and extend its function by also importing '''your''' _dll2 file.<br /> #::&gt; This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.<br /> #*As a maxim, you do not ever want to add a file to a repository that you did not create.<br /> #'''Do NOT think once when having to modify someone else's code.'''<br /> #*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.<br /> #*Moving on, what you can do here is:<br /> #::&gt; Create a new repository separate from your '''present repository'''.<br /> #::&gt; Branch the (target) person's project into your new repository. The term for such a &quot;cross-repository&quot; branch is fork.<br /> #::&gt; Inside your new repository, make a '''new branch''' where you make your modifications to their code as git commits with a merge request back into the ```main``` (of your new repository) at the end.<br /> #::&gt; If you are in the mood, you can even make a ```pull request``` back to the (target) person's project branch with your new code.<br /> #::&gt; But considering your own needs first, you can then add this '''new branch''' as a submodule in your '''present repository'''.<br /> #::&gt; Again, do not forget that untangling other people's code is a horrible process, so you want to keep yours and their code as separate as possible.<br /> #'''Do NOT included autogenerated files in your git repository.'''<br /> #*Do not forget that autogenerated files, e.g., .o and .d files, will change when you recompile them even if their source files have not.<br /> #*Instead, add the compilation instructions to your README and leave that to the user. Again, do not forget ```make``` files exist.<br /> #'''Do NOT forget to test your code on a workstation.'''<br /> #*It is not a matter of making sure your code runs on a specific workstation, but to remember that the end user will have a different machine with a different setup.<br /> #*For example, your code may require a compiler GLIBC &gt;= 2.29 that in turn requires Ubuntu &gt;=20.04. A quick check will reveal, as of August 2022, that most machines are running an older version.<br /> #*Therefore, do not forget to include a detailed list of instructions and system requirements when asking someone else to review your code.<br /> #*You do not want your reviewer (and therefore you) to spend ages just to debug software requirement related errors.<br /> #*As such, do not miss an opportunity to test your code on a 'fresh' machine. It may be helpful to even record the system specifications when your code runs successfully to aid with that.<br /> #'''Do NOT be afraid to clarify git related concepts as early as possible.'''<br /> #*Especially when it is your first time using Git.<br /> #'''Do NOT forget to share your mistakes and helpful pointers with your colleagues.'''<br /> #*We certainly do not wish to entertain the situation of multiple people making the same mistakes with the same reviewer.<br /> <br /> &quot;Do not&quot; counter: 37</div> Tkl35 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=The_Ten_Git-mmandments&diff=1024 The Ten Git-mmandments 2022-08-25T14:12:14Z <p>Tkl35: </p> <hr /> <div>Herein lies precious Git-related wisdom, do not disregard at your own convenience!<br /> <br /> #'''Do NOT treat Git repositories like Google Drive'''.<br /> #*Git repositories do not exist for you to backup all your files (e.g., cache, output and log files).<br /> #*Do not be trigger happy with ```git add --all```.<br /> #*Do not add whole directories.<br /> #*Maintain a minimalistic mentality, i.e., carefully consider what files are important with the focus on successfully allowing the user to run your code.<br /> #'''Do NOT include .pyc files, the entire __pycache__ folder and .DS_Store files.'''<br /> #*Basically, you have been warned.<br /> #'''Do NOT ignore .gitignore.'''<br /> #*They do not exist for no reason, create one to satisfy the above rules.<br /> #*Visit https://git-scm.com/docs/gitignore for more information on formatting one.<br /> #*Do not skip the following example:<br /> #::&gt; Sometimes, you might want to code using an IDE on your personal computer, git push and then git pull onto a workstation to run the code. <br /> #::&gt; As expected, you run into an error, nano into the file with the error and make the necessary changes.<br /> #::&gt; The code now works and you happily git push from the workstation, with all your output and cached folders.<br /> #'''Do NOT send a merge request with over 453 changed files - this is impossible to review!'''<br /> #*Do not operate with the mentality of only submitting completed working code.<br /> #*Do not forget that little and often with code review is better than the former.<br /> #*Besides the mundane rationale of catching your mistakes and getting feedback quicker rather than letting than accumulate, it allows the reviewer to better track and follow your changes.<br /> #'''Do NOT forget the concept and importance of source control.'''<br /> #*This is a big one. Basically, when you are coding as a team, or if your work is derived from another user, or needs to be passed on to future users, you must consider code maintenance and management.<br /> #*For example, as much as possible, do not explicitly include other people's code in your own repository, because when they update their code, you do not want to repeat the cloning or downloading process again, or have to sieve through all your and their code to find what has changed and needs to be updated. What you do want is to simply perform a ```git pull```. To that end, do not forget git submodules exist for a very good reason. See https://git-scm.com/book/en/v2/Git-Tools-Submodules.<br /> #*Along those lines, you also do not want to edit someone else's code as much as possible.<br /> #::&gt; For example, say you import the python package phreeqpy that serves as a wrapper for phreeqc, which is a piece of software written in C that you wish to use.<br /> #::&gt; You quickly realise one of the files, ```phreeqpy_dll.py``` is causing errors, and needs to be modified to suit your needs.<br /> #::&gt; You might wonder &quot;Wouldn't the easiest solution be to make a new repository for phreeqpy, replace the _dll file with a newly edited (by you) _dll2 file and adding it as a submodule (*gasps* something about explicitly including someone else's code)? Clearly, the _dll2 file contains everything required to perform the job!&quot;<br /> #::&gt; However, what you do not realise is that making a new repository means having to deal with the compilation of phreeqc underneath it (which is the job of phreeqpy), which will result in more work further down the road because you have effectively, albeit inadvertently, involved yourself in managing phreeqpy, and all the hard work required to make it interface with phreeqc, which is not your job.<br /> #::&gt; Indeed, do not rule out the possibility that it will probably be much less painful to make a single wrapper _dll2 file, and have '''your''' own module in '''your''' own repository import whatever is needed from the original '''unedited''' _dll file and extend its function by also importing '''your''' _dll2 file.<br /> #::&gt; This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.<br /> #*As a maxim, you do not ever want to add a file to a repository that you did not create.<br /> #'''Do NOT think once when having to modify someone else's code.'''<br /> #*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.<br /> #*Moving on, what you can do here is:<br /> #::&gt; Create a new repository separate from your '''present repository'''.<br /> #::&gt; Branch the (target) person's project into your new repository. The term for such a &quot;cross-repository&quot; branch is ```fork```.<br /> #::&gt; Inside your new repository, make a '''new branch''' where you make your modifications to their code as git commits with a merge request back into the ```main``` (of your new repository) at the end.<br /> #::&gt; If you are in the mood, you can even make a ```pull request``` back to the (target) person's project branch with your new code.<br /> #::&gt; But considering your own needs first, you can then add this '''new branch''' as a submodule in your '''present repository'''.<br /> #::&gt; Again, do not forget that untangling other people's code is a horrible process, so you want to keep yours and their code as separate as possible.<br /> #'''Do NOT included autogenerated files in your git repository.'''<br /> #*Do not forget that autogenerated files, e.g., .o and .d files, will change when you recompile them even if their source files have not.<br /> #*Instead, add the compilation instructions to your README and leave that to the user. Again, do not forget ```make``` files exist.<br /> #'''Do NOT forget to test your code on a workstation.'''<br /> #*It is not a matter of making sure your code runs on a specific workstation, but to remember that the end user will have a different machine with a different setup.<br /> #*For example, your code may require a compiler GLIBC &gt;= 2.29 that in turn requires Ubuntu &gt;=20.04. A quick check will reveal, as of August 2022, that most machines are running an older version.<br /> #*Therefore, do not forget to include a detailed list of instructions and system requirements when asking someone else to review your code.<br /> #*You do not want your reviewer (and therefore you) to spend ages just to debug software requirement related errors.<br /> #*As such, do not miss an opportunity to test your code on a 'fresh' machine. It may be helpful to even record the system specifications when your code runs successfully to aid with that.<br /> #'''Do NOT be afraid to clarify git related concepts as early as possible.'''<br /> #*Especially when it is your first time using Git.<br /> #'''Do NOT forget to share your mistakes and helpful pointers with your colleagues.'''<br /> #*We certainly do not wish to entertain the situation of multiple people making the same mistakes with the same reviewer.<br /> <br /> &quot;Do not&quot; counter: 37</div> Tkl35 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=The_Ten_Git-mmandments&diff=1023 The Ten Git-mmandments 2022-08-25T14:12:03Z <p>Tkl35: </p> <hr /> <div>Herein lies precious Git-related wisdom, do not disregard at your own convenience!<br /> <br /> #'''Do NOT treat Git repositories like Google Drive'''.<br /> #*Git repositories do not exist for you to backup all your files (e.g., cache, output and log files).<br /> #*Do not be trigger happy with ```git add --all```.<br /> #*Do not add whole directories.<br /> #*Maintain a minimalistic mentality, i.e., carefully consider what files are important with the focus on successfully allowing the user to run your code.<br /> #'''Do NOT include .pyc files, the entire __pycache__ folder and .DS_Store files.'''<br /> #*Basically, you have been warned.<br /> #'''Do NOT ignore .gitignore.'''<br /> #*They do not exist for no reason, create one to satisfy the above rules.<br /> #*Visit https://git-scm.com/docs/gitignore for more information on formatting one.<br /> #*Do not skip the following example:<br /> #::&gt; Sometimes, you might want to code using an IDE on your personal computer, git push and then git pull onto a workstation to run the code. <br /> #::&gt; As expected, you run into an error, nano into the file with the error and make the necessary changes.<br /> #::&gt; The code now works and you happily git push from the workstation, with all your output and cached folders.<br /> #'''Do NOT send a merge request with over 453 changed files - this is impossible to review!'''<br /> #*Do not operate with the mentality of only submitting completed working code.<br /> #*Do not forget that little and often with code review is better than the former.<br /> #*Besides the mundane rationale of catching your mistakes and getting feedback quicker rather than letting than accumulate, it allows the reviewer to better track and follow your changes.<br /> #'''Do NOT forget the concept and importance of source control.'''<br /> #*This is a big one. Basically, when you are coding as a team, or if your work is derived from another user, or needs to be passed on to future users, you must consider code maintenance and management.<br /> #*For example, as much as possible, do not explicitly include other people's code in your own repository, because when they update their code, you do not want to repeat the cloning or downloading process again, or have to sieve through all your and their code to find what has changed and needs to be updated. What you do want is to simply perform a ```git pull```. To that end, do not forget git submodules exist for a very good reason. See https://git-scm.com/book/en/v2/Git-Tools-Submodules.<br /> #*Along those lines, you also do not want to edit someone else's code as much as possible.<br /> #::&gt; For example, say you import the python package phreeqpy that serves as a wrapper for phreeqc, which is a piece of software written in C that you wish to use.<br /> #::&gt; You quickly realise one of the files, ```phreeqpy_dll.py``` is causing errors, and needs to be modified to suit your needs.<br /> #::&gt; You might wonder &quot;Wouldn't the easiest solution be to make a new repository for phreeqpy, replace the _dll file with a newly edited (by you) _dll2 file and adding it as a submodule (*gasps* something about explicitly including someone else's code)? Clearly, the _dll2 file contains everything required to perform the job!&quot;<br /> #::&gt; However, what you do not realise is that making a new repository means having to deal with the compilation of phreeqc underneath it (which is the job of phreeqpy), which will result in more work further down the road because you have effectively, albeit inadvertently, involved yourself in managing phreeqpy, and all the hard work required to make it interface with phreeqc, which is not your job.<br /> #::&gt; Indeed, do not rule out the possibility that it will probably be much less painful to make a single wrapper _dll2 file, and have '''your''' own module in '''your''' own repository import whatever is needed from the original '''unedited''' _dll file and extend its function by also importing '''your''' _dll2 file.<br /> #::&gt; This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.<br /> #*As a maxim, you do not ever want to add a file to a repository that you did not create.<br /> <br /> #'''Do NOT think once when having to modify someone else's code.'''<br /> #*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.<br /> #*Moving on, what you can do here is:<br /> #::&gt; Create a new repository separate from your '''present repository'''.<br /> #::&gt; Branch the (target) person's project into your new repository. The term for such a &quot;cross-repository&quot; branch is ```fork```.<br /> #::&gt; Inside your new repository, make a '''new branch''' where you make your modifications to their code as git commits with a merge request back into the ```main``` (of your new repository) at the end.<br /> #::&gt; If you are in the mood, you can even make a ```pull request``` back to the (target) person's project branch with your new code.<br /> #::&gt; But considering your own needs first, you can then add this '''new branch''' as a submodule in your '''present repository'''.<br /> #::&gt; Again, do not forget that untangling other people's code is a horrible process, so you want to keep yours and their code as separate as possible.<br /> #'''Do NOT included autogenerated files in your git repository.'''<br /> #*Do not forget that autogenerated files, e.g., .o and .d files, will change when you recompile them even if their source files have not.<br /> #*Instead, add the compilation instructions to your README and leave that to the user. Again, do not forget ```make``` files exist.<br /> #'''Do NOT forget to test your code on a workstation.'''<br /> #*It is not a matter of making sure your code runs on a specific workstation, but to remember that the end user will have a different machine with a different setup.<br /> #*For example, your code may require a compiler GLIBC &gt;= 2.29 that in turn requires Ubuntu &gt;=20.04. A quick check will reveal, as of August 2022, that most machines are running an older version.<br /> #*Therefore, do not forget to include a detailed list of instructions and system requirements when asking someone else to review your code.<br /> #*You do not want your reviewer (and therefore you) to spend ages just to debug software requirement related errors.<br /> #*As such, do not miss an opportunity to test your code on a 'fresh' machine. It may be helpful to even record the system specifications when your code runs successfully to aid with that.<br /> #'''Do NOT be afraid to clarify git related concepts as early as possible.'''<br /> #*Especially when it is your first time using Git.<br /> #'''Do NOT forget to share your mistakes and helpful pointers with your colleagues.'''<br /> #*We certainly do not wish to entertain the situation of multiple people making the same mistakes with the same reviewer.<br /> <br /> &quot;Do not&quot; counter: 37</div> Tkl35 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=The_Ten_Git-mmandments&diff=1022 The Ten Git-mmandments 2022-08-25T13:11:00Z <p>Tkl35: </p> <hr /> <div>Herein lies precious Git-related wisdom, do not disregard at your own risk!<br /> <br /> #'''Do NOT treat Git repositories like Google Drive'''.<br /> #*Git repositories do not exist to for you to backup all your files (e.g., cache, output and log files).<br /> #*Do not be trigger happy with ```git add --all```.<br /> #*In other words, do not add whole directories.<br /> #*Maintain a minimalistic mentality, i.e., carefully consider what files are important with the focus on successfully allowing the user to run your code.<br /> #'''Do NOT include .pyc files, the entire __pycache__ folder and .DS_Store files.'''<br /> #*Basically, you have been warned.<br /> #'''Do NOT ignore .gitignore.'''<br /> #*They do not exist for no reason, create one to satisfy the above rules.<br /> #*Visit https://git-scm.com/docs/gitignore for more information on formatting one.<br /> #*Do not skip the following example:<br /> #::&gt; Sometimes, you might want to code using an IDE on your personal computer, git push and then git pull onto a workstation to run the code. <br /> #::&gt; As expected, you run into an error, nano into the file with the error and make the necessary changes.<br /> #::&gt; The code now works and you happily git push from the workstation, with all your output and cached folders.<br /> #'''Do NOT send a merge request with over 453 changed files - this is impossible to review!'''<br /> #*Do not operate with the mentality of only submitting completed working code.<br /> #*Do not forget that little and often with code review is better than the former.<br /> #*Besides the mundane rationale of catching your mistakes and getting feedback quicker rather than letting than accumulate, it allows the reviewer to better track and follow your changes.<br /> #'''Do NOT foster a habit '''<br /> <br /> <br /> <br /> <br /> &quot;Do not&quot; counter: 12+</div> Tkl35 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=The_Ten_Git-mmandments&diff=1021 The Ten Git-mmandments 2022-08-25T12:47:47Z <p>Tkl35: </p> <hr /> <div>Herein lies precious Git-related wisdom, disregard at your own risk!<br /> <br /> # '''Do NOT treat Git repositories like Google Drive'''.</div> Tkl35 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=The_Ten_Git-mmandments&diff=1020 The Ten Git-mmandments 2022-08-25T12:46:29Z <p>Tkl35: Created page with &quot;Herein lies precious Git-related wisdom, disregard at your own risk! * Do NOT treat Git repositories like your Google Drive.&quot;</p> <hr /> <div>Herein lies precious Git-related wisdom, disregard at your own risk!<br /> <br /> * Do NOT treat Git repositories like your Google Drive.</div> Tkl35 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=Main_Page&diff=1019 Main Page 2022-08-25T12:44:35Z <p>Tkl35: </p> <hr /> <div>&lt;div style=&quot;text-align: center;&quot;&gt;<br /> ''<br /> # _________ # ___ ___ # ______ # ___ __ __ # # _______ # ______ # ______ # __ __ # ______ #<br /> #/________/\ #/__/\ /__/\ #/_____/\ #/__//_//_/\ # #/______/\ #/_____/\ #/_____/\ #/_/\/_/\ #/_____/\ #<br /> #\__.::.__\/ #\::\ \\ \ \ #\:::_ \ \ #\::\| \| \ \ # #\::::__\/__ #\:::_ \ \ #\:::_ \ \ #\:\ \:\ \ #\:::_ \ \ #<br /> # \::\ \ # \::\/_\ .\ \ # \:\ \ \ \ # \:. \ \ # # \:\ /____/\ # \:(_) ) )_ # \:\ \ \ \ # \:\ \:\ \ # \:(_) \ \ #<br /> # \::\ \ # \:: ___::\ \ # \:\ \ \ \ # \:.\-/\ \ \ # # \:\\_ _\/ # \: __ `\ \ # \:\ \ \ \ # \:\ \:\ \ # \: ___\/ #<br /> # \::\ \ # \: \ \\::\ \# \:\_\ \ \ # \. \ \ \ \# # \:\_\ \ \ # \ \ `\ \ \ # \:\_\ \ \ # \:\_\:\ \ # \ \ \ #<br /> # \__\/ # \__\/ \::\/# \_____\/ # \__\/ \__\/# # \_____\/ # \_\/ \_\/ # \_____\/ # \_____\/ # \_\/ #<br /> # # # # # # # # # # #<br /> ''<br /> &lt;/div&gt;<br /> <br /> Hello, Guten Abend, and Bienvenue to the new Thom Group Wiki. (Apparently evenings are good times to read the Wiki.)<br /> <br /> In this Wiki you can find various pieces of useful information, such as when group meetings are, who is going to bring cake, how to run a particular calculation or perform a certain computer trick, who's using which computer in the group, and so on. You can also see how fun we are as a group by looking at our various photos.<br /> <br /> =Group Calendar=<br /> https://calendar.google.com/calendar/render?mode=day&amp;date=20160601T153539#main_7%7Cday-1+23745+23745+23745<br /> <br /> {{Special:IframePage}}<br /> <br /> =Group Meetings=<br /> <br /> Past Group Meetings [[Past Group Meetings|here]].<br /> <br /> ===Summer 2022===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! style=&quot;width: 20ex;&quot; |'''Date''' || style=&quot;width: 18ex;&quot; | '''Talk''' || style=&quot;width: 18ex;&quot; | '''Cake''' <br /> |-<br /> |25th July || WATOC Review &amp; IPLU Discussion || <br /> |-<br /> |8th August || Brian || Andreea<br /> |-<br /> |30th August || Nick || Daniel<br /> |-<br /> |12th September|| Interns || Alex<br /> |}<br /> <br /> =Journal Club=<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! style=&quot;width: 20ex;&quot; |'''Date''' || style=&quot;width: 18ex;&quot; | '''Contributor''' || style=&quot;width: 36ex;&quot; | '''Paper''' <br /> |-<br /> | 8 Oct 2021 || Kripa || [https://arxiv.org/pdf/1712.01815.pdf/ Mastering Chess and Shogi by Self-Play with a General Reinforcement Learning Algorithm]<br /> |-<br /> | 5 Nov 2021 || Brian || [https://pubs.acs.org/doi/10.1021/acs.jpca.1c05962 Neat, Simple and Wrong: Debunking Electrostatic Fallacies Regarding Noncovalent Interactions]<br /> |-<br /> | 6 Dec 2021 || Kripa || [https://pubs.acs.org/doi/10.1021/acs.jpclett.1c03214 Quantum Algorithm for Full Configuration Interaction Calculations without Controlled Time Evolutions]<br /> |-<br /> | 11 Feb 2022 || Nick || [https://www.nature.com/articles/s41598-021-00053-8 Mapping the NFT revolution: market trends, trade networks, and visual features]<br /> |-<br /> | 11 Mar 2022 || Andreea || [https://link.springer.com/article/10.1007/BF02650179 Simulating physics with computers]<br /> |-<br /> | 27 Apr 2022 || Fabio || [https://arxiv.org/pdf/1912.06462.pdf Rethinking Superdeterminism]<br /> |-<br /> | 25 May 2022 || Kripa || [https://www.frontiersin.org/articles/10.3389/fnhum.2014.00068/full#h1 The experience of mathematical beauty and its neural correlates]<br /> |-<br /> | 17 Aug 2022 || Nick || [https://onlinelibrary.wiley.com/doi/10.1002/nadc.20224120702 Scientists must resist cancel culture] [https://pubs.acs.org/doi/10.1021/acs.jpclett.2c02242 Words Matter: On the debate over free speech, inclusivity, and academic excellence]<br /> |}<br /> <br /> =Summer 'Interns'=<br /> Past Summer Interns [[Past Summer Interns|here]].<br /> ==2022==<br /> {| class=&quot;wikitable&quot;<br /> ! style=&quot;width: 18ex;&quot; |'''Name''' || style=&quot;width: 18ex;&quot; | '''Dates''' || style=&quot;width: 25ex;&quot; | '''Project'''|| style=&quot;width: 18ex;&quot; | '''Machine'''<br /> |-<br /> | Douglas Russell || - || IPLU || hypatia<br /> |-<br /> | Theo Hatcher || - || IPLU || chucksty<br /> |-<br /> | Motoki Yamano || - || IPLU || hypatia<br /> |-<br /> | King Lam || - || IPLU || chucksty<br /> |-<br /> | Juan Fernandez Pottecher || - || Strong Correlation || hylas<br /> |-<br /> | Max Howe || - || Singlet Fission || moonraker<br /> |}<br /> <br /> = [[Group_List | Group List]] =<br /> The full timeline of all current and past group members is available [https://wikis.ch.cam.ac.uk/thom/wiki/index.php/Group_List here]. NB autogenerated by `thom-fs-common/old-ifs-thom/cbh31/groupwiki`<br /> <br /> An up to date list of group members is also available [http://www.ch.cam.ac.uk/group/thom here].<br /> <br /> [[File:AJWT_group_8_21_taken_by_Nathan Pitt_©University_of_Cambridge_1274_M.jpg|1000px|thumb|center|Thom Group photo - taken by Nathan Pitt, ©University of Cambridge, August 2021]]<br /> &lt;div style=&quot;text-align: center;&quot;&gt;<br /> Front row, left to right: Anna Bui, Brian Zhao, Bang C. Huynh, Arta Safari, Maria-Andreea Filip&lt;br&gt;<br /> Back row, right to left: David Izuogu, Kripa Panchagnula, Zian Wang, Dr Alex Thom&lt;br&gt;<br /> Not in picture: Fabio Albertani, Nicholas Lee, Tarik Benyahia, César Feniou, Benjamin Mokhtar<br /> &lt;/div&gt;<br /> <br /> <br /> [[File:AJWT_group_photo_2_5_19-4926_taken_by_Nathan_Pitt_University_of_Cambridge-tighter.jpg|500px|thumb|center|Thom Group photo - taken by Nathan Pitt, ©University of Cambridge, May 2019]]<br /> [[File:AJWT_Group_photo-5470_taken_by_Nathan_Pitt_University_of_Cambridge.jpg|500px|thumb|center|Thom Group photo - taken by Nathan Pitt, ©University of Cambridge, November 2017]]<br /> <br /> = [[Computer_and_Storage_List | Computing Resources]] =<br /> - Group computers available.<br /> <br /> - Clusters available.<br /> <br /> - Storage available.<br /> <br /> = Computing Setup Guide =<br /> Anaconda takes up a lot of space on /home so it's worth running<br /> <br /> mv ~/.conda /scratch/$USER/.conda<br /> ln -s /scratch/$USER/.conda ~/.conda<br /> <br /> = [[Introduction | Introduction to basic shell commands]] = <br /> - There are a number of tutorials available which document basic operations that are useful including:<br /> <br /> # General bash commands<br /> # Setting up cygwin<br /> # Setting up [https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key ssh keys] and general bash commands what are helpful<br /> # Setting up ssh config files<br /> # using [[GIT]]<br /> # Useful cerebro queue commands<br /> # Some [[vim]] tidbits<br /> <br /> Currently undergoing construction.<br /> <br /> = How to connect to department machines =<br /> <br /> '''On Mac/WSL:'''<br /> <br /> # Check you have an Admitto account and collect your password from https://www.ch.cam.ac.uk/computing/admitto-service<br /> # In the terminal run the command ''ssh -X crsid@citadel.ch.cam.ac.uk''<br /> # When prompted input your Admitto username (crsid) and password <br /> # Once this has worked run the command ''ssh -X crsid@machinename'' in the terminal to log into a particular machine<br /> <br /> Set up logging in without a password:<br /> <br /> # Generate an ssh key by running the command ''ssh-keygen'' in the terminal, as described in detail in the section &quot;Introduction to basic shell commands&quot;<br /> # Use ''cd ~/.ssh'' to navigate to the directory holding the keys, and copy the text from the file &quot;id_rsa.pub&quot; beginning with ssh-rsa. This is your public ssh key<br /> # Log into the department citadel machine, and create / navigate to a directory called .ssh<br /> # Use ''chmod 700 .ssh'' to set permissions for the directory<br /> # Input ''vi authorized_keys'' to open up the vi text editor. Press i, then paste in your public ssh key. Press escape, then type '':wq'' and press enter to write and quit the editor <br /> # Log into the particular machine you want to ssh to, and repeat steps 3 to 5<br /> # Exit back to your machine and navigate to the home directory<br /> # Input ''vi .ssh/config'' to open the vi text editor. Press i, then paste in the following, with your crsid and machine name in the places given:<br /> Host citadel<br /> User crsid<br /> Hostname citadel.ch.cam.ac.uk<br /> ForwardAgent yes<br /> ProxyCommand none<br /> Host machinename<br /> Hostname machinename<br /> ProxyCommand ssh citadel -W %h:%p<br /> User crsid<br /> ForwardAgent yes<br /> ServerAliveInterval 60<br /> ServerAliveCountMax 10<br /> <br /> <br /> Press escape, then input '':wq'' followed by enter to exit the editor.<br /> You can now log straight into citadel with ''ssh citadel'' or straight into your machine with ''ssh machinename''. The last two commands stop the ssh being killed if you are idle for too long. The ''ServerAliveInterval'' is how many seconds to ping a null packet, and the ''ServerAliveCountMax'' are how many consecutive times it needs to fail for the ssh to be killed.<br /> <br /> <br /> '''File Transfer Protocol :'''<br /> <br /> You may want to transfer files between department machines and your computer. The standard way is to ''scp'' via the terminal with commands :<br /> UPLOAD : <br /> scp -o ProxyCommand=&quot;ssh crsid@citadel.ch.cam.ac.uk nc machinename 22&quot; LocalPath/FileName crsid@machinename.ch.cam.ac.uk:/RemotePath<br /> DOWNLOAD : <br /> scp -o ProxyCommand=&quot;ssh crsid@citadel.ch.cam.ac.uk nc machinename 22&quot; crsid@machinename.ch.cam.ac.uk:/RemotePath/FileName LocalPath<br /> <br /> However, a more convenient way is to set up a File Transfer Protocol (FTP) between machines. It can come with a graphic user interface, where you can drag and drop files from the department machine to your computer. <br /> <br /> &lt;u&gt;ON WINDOWS&lt;/u&gt;:<br /> <br /> I recommend the WinSCP software. You can download it from [https://winscp.net/eng/download.php here].<br /> Once installed, click ''New Session'', and choose ''SFTP'' protocol with :<br /> Hostname = machinename<br /> Port number = 22<br /> Username = crsid<br /> Leave 'Password' entry empty.<br /> Then click on ''Advanced...'', ''Tunnel'' tab, check the ''Connect through SSH tunnel'' tickbox and enter:<br /> Hostname = citadel.ch.cam.ac.uk<br /> Port number = 22<br /> Username = crsid<br /> Leave 'Password' entry empty.<br /> Click ''OK'' and click ''Save'', and finally ''Login''. Enter your admitto password twice.<br /> You can now navigate in the directories of the remote machine on the right tab, and of your local computer on the left tab, and you can transfer files between the two with a drag and drop. Enjoy !<br /> <br /> <br /> <br /> &lt;u&gt;ON MAC\LINUX&lt;/u&gt;:<br /> <br /> You can download FileZilla for [https://filezilla-project.org/download.php?platform=osx MacOS] or [https://filezilla-project.org/download.php?platform=linux64 linux].<br /> The problem is that FileZilla does not support tunnel ssh. To open the connection, you need to use a ssh client like puTTY.<br /> On MacOS please follow [https://phoenixnap.com/kb/install-putty-on-mac this guide].<br /> <br /> On Linux you can do :<br /> sudo apt-get install -y putty<br /> Open it by typing ''putty'' on the terminal. The interface should open.<br /> Type the following entries :<br /> <br /> in the ''SSH/Tunnels'' tab :<br /> Source Port = 3111 <br /> Destination = machinename:22 <br /> local <br /> auto<br /> and click ''Add''. (source port can be any number &gt; 1024)<br /> <br /> in the ''session'' tab :<br /> Host Name = citadel.ch.cam.ac.uk <br /> port = 22 <br /> connection type = SSH<br /> Enter a name for this connection in the ''saved sessions'' entry, and click ''Save''.<br /> <br /> Now click ''Open''.<br /> A terminal should open, type your crsid and your admitto password, you're now logged into Citadel (it's normal that it's not your machine).<br /> <br /> Now open FileZilla, and enter :<br /> Host = sftp://localhost<br /> username = crsid<br /> password = admitto password<br /> port = 3111 <br /> and click ''Quickconnect''. (port needs to be the same as source port in puTTY).<br /> <br /> A window will open (Unknown host key), click ''OK''. Hopefully the connection is successful. <br /> <br /> You can now navigate in the directories of the remote machine on the right tab, and of your local computer on the left tab, and you can transfer files between the two with a drag and drop. Enjoy !<br /> <br /> = Useful Software =<br /> # Using [[QChem]]<br /> # Using [[QCMagic]]<br /> # [[SimpleDMC]]<br /> # [[MRCC]]<br /> # [[GAMESS]]<br /> <br /> = Useful Information =<br /> # Guidelines on [[Code Review]]<br /> # How to do things relating to [[HANDE]]<br /> # How to run PySCF or other [[Python software on Archer]]<br /> # How to run QChem on [[darwin]]<br /> # Where to get [[Travel Money]]<br /> # Backed-up [[Storage]]<br /> # [[How to get IQMol to run a local version of Q-Chem via SSH]]<br /> # [[Slow ubuntu dash]]<br /> # [[Persistent X]] sessions for remote working<br /> # [[Paper submission]]<br /> # [[Getting Started with cerebro]]<br /> # [[Things to do before leaving]]<br /> # [[The Ten Git-mmandments]]: what NOT to do<br /> <br /> = [[Archiving_data | Archiving data for the university repository]] =<br /> <br /> = [[Website_to_do | To-do list for the Thom Group Website]] =<br /> <br /> = [[Group_activities | Group Activities]] =<br /> <br /> = To-do list for the Wiki=<br /> <br /> - A pretty picture<br /> <br /> - A &quot;How to:&quot; page on setting up cygwin, ssh keys and general bash commands what are helpful<br /> <br /> - A &quot;How to:&quot; page on using qchem<br /> <br /> - A Pretty picture for the $wgLogo</div> Tkl35 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=Ten_Git-mmandments&diff=1018 Ten Git-mmandments 2022-08-25T12:44:04Z <p>Tkl35: Created page with &quot;Herein lies a compilation of Git-related wisdom, disobey at your own risk!&quot;</p> <hr /> <div>Herein lies a compilation of Git-related wisdom, disobey at your own risk!</div> Tkl35 https://wikis.ch.cam.ac.uk/thom/wiki/index.php?title=Main_Page&diff=1017 Main Page 2022-08-25T12:42:16Z <p>Tkl35: </p> <hr /> <div>&lt;div style=&quot;text-align: center;&quot;&gt;<br /> ''<br /> # _________ # ___ ___ # ______ # ___ __ __ # # _______ # ______ # ______ # __ __ # ______ #<br /> #/________/\ #/__/\ /__/\ #/_____/\ #/__//_//_/\ # #/______/\ #/_____/\ #/_____/\ #/_/\/_/\ #/_____/\ #<br /> #\__.::.__\/ #\::\ \\ \ \ #\:::_ \ \ #\::\| \| \ \ # #\::::__\/__ #\:::_ \ \ #\:::_ \ \ #\:\ \:\ \ #\:::_ \ \ #<br /> # \::\ \ # \::\/_\ .\ \ # \:\ \ \ \ # \:. \ \ # # \:\ /____/\ # \:(_) ) )_ # \:\ \ \ \ # \:\ \:\ \ # \:(_) \ \ #<br /> # \::\ \ # \:: ___::\ \ # \:\ \ \ \ # \:.\-/\ \ \ # # \:\\_ _\/ # \: __ `\ \ # \:\ \ \ \ # \:\ \:\ \ # \: ___\/ #<br /> # \::\ \ # \: \ \\::\ \# \:\_\ \ \ # \. \ \ \ \# # \:\_\ \ \ # \ \ `\ \ \ # \:\_\ \ \ # \:\_\:\ \ # \ \ \ #<br /> # \__\/ # \__\/ \::\/# \_____\/ # \__\/ \__\/# # \_____\/ # \_\/ \_\/ # \_____\/ # \_____\/ # \_\/ #<br /> # # # # # # # # # # #<br /> ''<br /> &lt;/div&gt;<br /> <br /> Hello, Guten Abend, and Bienvenue to the new Thom Group Wiki. (Apparently evenings are good times to read the Wiki.)<br /> <br /> In this Wiki you can find various pieces of useful information, such as when group meetings are, who is going to bring cake, how to run a particular calculation or perform a certain computer trick, who's using which computer in the group, and so on. You can also see how fun we are as a group by looking at our various photos.<br /> <br /> =Group Calendar=<br /> https://calendar.google.com/calendar/render?mode=day&amp;date=20160601T153539#main_7%7Cday-1+23745+23745+23745<br /> <br /> {{Special:IframePage}}<br /> <br /> =Group Meetings=<br /> <br /> Past Group Meetings [[Past Group Meetings|here]].<br /> <br /> ===Summer 2022===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! style=&quot;width: 20ex;&quot; |'''Date''' || style=&quot;width: 18ex;&quot; | '''Talk''' || style=&quot;width: 18ex;&quot; | '''Cake''' <br /> |-<br /> |25th July || WATOC Review &amp; IPLU Discussion || <br /> |-<br /> |8th August || Brian || Andreea<br /> |-<br /> |30th August || Nick || Daniel<br /> |-<br /> |12th September|| Interns || Alex<br /> |}<br /> <br /> =Journal Club=<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! style=&quot;width: 20ex;&quot; |'''Date''' || style=&quot;width: 18ex;&quot; | '''Contributor''' || style=&quot;width: 36ex;&quot; | '''Paper''' <br /> |-<br /> | 8 Oct 2021 || Kripa || [https://arxiv.org/pdf/1712.01815.pdf/ Mastering Chess and Shogi by Self-Play with a General Reinforcement Learning Algorithm]<br /> |-<br /> | 5 Nov 2021 || Brian || [https://pubs.acs.org/doi/10.1021/acs.jpca.1c05962 Neat, Simple and Wrong: Debunking Electrostatic Fallacies Regarding Noncovalent Interactions]<br /> |-<br /> | 6 Dec 2021 || Kripa || [https://pubs.acs.org/doi/10.1021/acs.jpclett.1c03214 Quantum Algorithm for Full Configuration Interaction Calculations without Controlled Time Evolutions]<br /> |-<br /> | 11 Feb 2022 || Nick || [https://www.nature.com/articles/s41598-021-00053-8 Mapping the NFT revolution: market trends, trade networks, and visual features]<br /> |-<br /> | 11 Mar 2022 || Andreea || [https://link.springer.com/article/10.1007/BF02650179 Simulating physics with computers]<br /> |-<br /> | 27 Apr 2022 || Fabio || [https://arxiv.org/pdf/1912.06462.pdf Rethinking Superdeterminism]<br /> |-<br /> | 25 May 2022 || Kripa || [https://www.frontiersin.org/articles/10.3389/fnhum.2014.00068/full#h1 The experience of mathematical beauty and its neural correlates]<br /> |-<br /> | 17 Aug 2022 || Nick || [https://onlinelibrary.wiley.com/doi/10.1002/nadc.20224120702 Scientists must resist cancel culture] [https://pubs.acs.org/doi/10.1021/acs.jpclett.2c02242 Words Matter: On the debate over free speech, inclusivity, and academic excellence]<br /> |}<br /> <br /> =Summer 'Interns'=<br /> Past Summer Interns [[Past Summer Interns|here]].<br /> ==2022==<br /> {| class=&quot;wikitable&quot;<br /> ! style=&quot;width: 18ex;&quot; |'''Name''' || style=&quot;width: 18ex;&quot; | '''Dates''' || style=&quot;width: 25ex;&quot; | '''Project'''|| style=&quot;width: 18ex;&quot; | '''Machine'''<br /> |-<br /> | Douglas Russell || - || IPLU || hypatia<br /> |-<br /> | Theo Hatcher || - || IPLU || chucksty<br /> |-<br /> | Motoki Yamano || - || IPLU || hypatia<br /> |-<br /> | King Lam || - || IPLU || chucksty<br /> |-<br /> | Juan Fernandez Pottecher || - || Strong Correlation || hylas<br /> |-<br /> | Max Howe || - || Singlet Fission || moonraker<br /> |}<br /> <br /> = [[Group_List | Group List]] =<br /> The full timeline of all current and past group members is available [https://wikis.ch.cam.ac.uk/thom/wiki/index.php/Group_List here]. NB autogenerated by `thom-fs-common/old-ifs-thom/cbh31/groupwiki`<br /> <br /> An up to date list of group members is also available [http://www.ch.cam.ac.uk/group/thom here].<br /> <br /> [[File:AJWT_group_8_21_taken_by_Nathan Pitt_©University_of_Cambridge_1274_M.jpg|1000px|thumb|center|Thom Group photo - taken by Nathan Pitt, ©University of Cambridge, August 2021]]<br /> &lt;div style=&quot;text-align: center;&quot;&gt;<br /> Front row, left to right: Anna Bui, Brian Zhao, Bang C. Huynh, Arta Safari, Maria-Andreea Filip&lt;br&gt;<br /> Back row, right to left: David Izuogu, Kripa Panchagnula, Zian Wang, Dr Alex Thom&lt;br&gt;<br /> Not in picture: Fabio Albertani, Nicholas Lee, Tarik Benyahia, César Feniou, Benjamin Mokhtar<br /> &lt;/div&gt;<br /> <br /> <br /> [[File:AJWT_group_photo_2_5_19-4926_taken_by_Nathan_Pitt_University_of_Cambridge-tighter.jpg|500px|thumb|center|Thom Group photo - taken by Nathan Pitt, ©University of Cambridge, May 2019]]<br /> [[File:AJWT_Group_photo-5470_taken_by_Nathan_Pitt_University_of_Cambridge.jpg|500px|thumb|center|Thom Group photo - taken by Nathan Pitt, ©University of Cambridge, November 2017]]<br /> <br /> = [[Computer_and_Storage_List | Computing Resources]] =<br /> - Group computers available.<br /> <br /> - Clusters available.<br /> <br /> - Storage available.<br /> <br /> = Computing Setup Guide =<br /> Anaconda takes up a lot of space on /home so it's worth running<br /> <br /> mv ~/.conda /scratch/$USER/.conda<br /> ln -s /scratch/$USER/.conda ~/.conda<br /> <br /> = [[Introduction | Introduction to basic shell commands]] = <br /> - There are a number of tutorials available which document basic operations that are useful including:<br /> <br /> # General bash commands<br /> # Setting up cygwin<br /> # Setting up [https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key ssh keys] and general bash commands what are helpful<br /> # Setting up ssh config files<br /> # using [[GIT]]<br /> # Useful cerebro queue commands<br /> # Some [[vim]] tidbits<br /> <br /> Currently undergoing construction.<br /> <br /> = How to connect to department machines =<br /> <br /> '''On Mac/WSL:'''<br /> <br /> # Check you have an Admitto account and collect your password from https://www.ch.cam.ac.uk/computing/admitto-service<br /> # In the terminal run the command ''ssh -X crsid@citadel.ch.cam.ac.uk''<br /> # When prompted input your Admitto username (crsid) and password <br /> # Once this has worked run the command ''ssh -X crsid@machinename'' in the terminal to log into a particular machine<br /> <br /> Set up logging in without a password:<br /> <br /> # Generate an ssh key by running the command ''ssh-keygen'' in the terminal, as described in detail in the section &quot;Introduction to basic shell commands&quot;<br /> # Use ''cd ~/.ssh'' to navigate to the directory holding the keys, and copy the text from the file &quot;id_rsa.pub&quot; beginning with ssh-rsa. This is your public ssh key<br /> # Log into the department citadel machine, and create / navigate to a directory called .ssh<br /> # Use ''chmod 700 .ssh'' to set permissions for the directory<br /> # Input ''vi authorized_keys'' to open up the vi text editor. Press i, then paste in your public ssh key. Press escape, then type '':wq'' and press enter to write and quit the editor <br /> # Log into the particular machine you want to ssh to, and repeat steps 3 to 5<br /> # Exit back to your machine and navigate to the home directory<br /> # Input ''vi .ssh/config'' to open the vi text editor. Press i, then paste in the following, with your crsid and machine name in the places given:<br /> Host citadel<br /> User crsid<br /> Hostname citadel.ch.cam.ac.uk<br /> ForwardAgent yes<br /> ProxyCommand none<br /> Host machinename<br /> Hostname machinename<br /> ProxyCommand ssh citadel -W %h:%p<br /> User crsid<br /> ForwardAgent yes<br /> ServerAliveInterval 60<br /> ServerAliveCountMax 10<br /> <br /> <br /> Press escape, then input '':wq'' followed by enter to exit the editor.<br /> You can now log straight into citadel with ''ssh citadel'' or straight into your machine with ''ssh machinename''. The last two commands stop the ssh being killed if you are idle for too long. The ''ServerAliveInterval'' is how many seconds to ping a null packet, and the ''ServerAliveCountMax'' are how many consecutive times it needs to fail for the ssh to be killed.<br /> <br /> <br /> '''File Transfer Protocol :'''<br /> <br /> You may want to transfer files between department machines and your computer. The standard way is to ''scp'' via the terminal with commands :<br /> UPLOAD : <br /> scp -o ProxyCommand=&quot;ssh crsid@citadel.ch.cam.ac.uk nc machinename 22&quot; LocalPath/FileName crsid@machinename.ch.cam.ac.uk:/RemotePath<br /> DOWNLOAD : <br /> scp -o ProxyCommand=&quot;ssh crsid@citadel.ch.cam.ac.uk nc machinename 22&quot; crsid@machinename.ch.cam.ac.uk:/RemotePath/FileName LocalPath<br /> <br /> However, a more convenient way is to set up a File Transfer Protocol (FTP) between machines. It can come with a graphic user interface, where you can drag and drop files from the department machine to your computer. <br /> <br /> &lt;u&gt;ON WINDOWS&lt;/u&gt;:<br /> <br /> I recommend the WinSCP software. You can download it from [https://winscp.net/eng/download.php here].<br /> Once installed, click ''New Session'', and choose ''SFTP'' protocol with :<br /> Hostname = machinename<br /> Port number = 22<br /> Username = crsid<br /> Leave 'Password' entry empty.<br /> Then click on ''Advanced...'', ''Tunnel'' tab, check the ''Connect through SSH tunnel'' tickbox and enter:<br /> Hostname = citadel.ch.cam.ac.uk<br /> Port number = 22<br /> Username = crsid<br /> Leave 'Password' entry empty.<br /> Click ''OK'' and click ''Save'', and finally ''Login''. Enter your admitto password twice.<br /> You can now navigate in the directories of the remote machine on the right tab, and of your local computer on the left tab, and you can transfer files between the two with a drag and drop. Enjoy !<br /> <br /> <br /> <br /> &lt;u&gt;ON MAC\LINUX&lt;/u&gt;:<br /> <br /> You can download FileZilla for [https://filezilla-project.org/download.php?platform=osx MacOS] or [https://filezilla-project.org/download.php?platform=linux64 linux].<br /> The problem is that FileZilla does not support tunnel ssh. To open the connection, you need to use a ssh client like puTTY.<br /> On MacOS please follow [https://phoenixnap.com/kb/install-putty-on-mac this guide].<br /> <br /> On Linux you can do :<br /> sudo apt-get install -y putty<br /> Open it by typing ''putty'' on the terminal. The interface should open.<br /> Type the following entries :<br /> <br /> in the ''SSH/Tunnels'' tab :<br /> Source Port = 3111 <br /> Destination = machinename:22 <br /> local <br /> auto<br /> and click ''Add''. (source port can be any number &gt; 1024)<br /> <br /> in the ''session'' tab :<br /> Host Name = citadel.ch.cam.ac.uk <br /> port = 22 <br /> connection type = SSH<br /> Enter a name for this connection in the ''saved sessions'' entry, and click ''Save''.<br /> <br /> Now click ''Open''.<br /> A terminal should open, type your crsid and your admitto password, you're now logged into Citadel (it's normal that it's not your machine).<br /> <br /> Now open FileZilla, and enter :<br /> Host = sftp://localhost<br /> username = crsid<br /> password = admitto password<br /> port = 3111 <br /> and click ''Quickconnect''. (port needs to be the same as source port in puTTY).<br /> <br /> A window will open (Unknown host key), click ''OK''. Hopefully the connection is successful. <br /> <br /> You can now navigate in the directories of the remote machine on the right tab, and of your local computer on the left tab, and you can transfer files between the two with a drag and drop. Enjoy !<br /> <br /> = Useful Software =<br /> # Using [[QChem]]<br /> # Using [[QCMagic]]<br /> # [[SimpleDMC]]<br /> # [[MRCC]]<br /> # [[GAMESS]]<br /> <br /> = Useful Information =<br /> # Guidelines on [[Code Review]]<br /> # How to do things relating to [[HANDE]]<br /> # How to run PySCF or other [[Python software on Archer]]<br /> # How to run QChem on [[darwin]]<br /> # Where to get [[Travel Money]]<br /> # Backed-up [[Storage]]<br /> # [[How to get IQMol to run a local version of Q-Chem via SSH]]<br /> # [[Slow ubuntu dash]]<br /> # [[Persistent X]] sessions for remote working<br /> # [[Paper submission]]<br /> # [[Getting Started with cerebro]]<br /> # [[Things to do before leaving]]<br /> # The [[Ten Git-mmandments]]: what NOT to do<br /> <br /> = [[Archiving_data | Archiving data for the university repository]] =<br /> <br /> = [[Website_to_do | To-do list for the Thom Group Website]] =<br /> <br /> = [[Group_activities | Group Activities]] =<br /> <br /> = To-do list for the Wiki=<br /> <br /> - A pretty picture<br /> <br /> - A &quot;How to:&quot; page on setting up cygwin, ssh keys and general bash commands what are helpful<br /> <br /> - A &quot;How to:&quot; page on using qchem<br /> <br /> - A Pretty picture for the $wgLogo</div> Tkl35