```flow st=>start: Start eYes=>end: You can use Triton cluster eMaybe=>end: let's consider your case eNo=>end: You cannot use Triton cluster cond1=>condition: Employed by Aalto? cond2=>condition: Bachelor student? cond3=>condition: Master student? cond4=>condition: Finishing dr. thesis at Aalto? cond5=>condition: Visitor? cond6=>condition: Affiliated with Aalto research group? cond7=>condition: Will you use triton for research? cond8=>condition: Will the research be published in a peer reviewed journal? st->cond1 cond1(yes,right)->cond6 cond1(no,bottom)->cond2 cond2(yes,right)->eNo cond2(no)->cond3 cond3(yes,right)->cond6 cond3(no)->cond4 cond4(yes,right)->cond6 cond4(no)->cond5 cond5(yes)->cond6 cond5(no)->eNo cond6(yes,left)->eYes cond6(no,bottom)->cond7 cond7(yes)->cond8 cond7(no)->eNo cond8(yes)->eMaybe cond8(no)->eNo ``` ### another version I remember cases of bachelors affiliated with research groups and not sure if paid by Aalto. ```flow st=>start: Start eYes=>end: You can use Triton cluster eMaybe=>end: let's consider your case eNo=>end: You cannot use Triton cluster cond1=>condition: Employed by Aalto? cond2=>condition: Bachelor student? cond3=>condition: Bachelor or Master student? cond4=>condition: Finishing dr. thesis at Aalto? cond5=>condition: Visitor? cond6=>condition: Affiliated with Aalto research group? cond7=>condition: Will you use triton for research? cond8=>condition: Will the research be published in a peer reviewed journal? st->cond1 cond1(yes,right)->cond6 cond1(no,bottom)->cond3 cond3(yes,right)->cond6 cond3(no)->cond4 cond4(yes,right)->cond6 cond4(no)->cond5 cond5(yes)->cond6 cond5(no)->eNo cond6(yes,left)->eYes cond6(no,bottom)->cond7 cond7(yes)->cond8 cond7(no)->eNo cond8(yes)->eMaybe cond8(no)->eNo ``` // we could revise it 1. Do you have Aalto account? 2. Did you read and accept the triton use policy? // this has that it should be used for research. THen we don't need point 5 below. 3. Are you affiliated with a research group? 4. no -> no account 5. yes -> 5. We can rename it "academic research" to separate it from research (=data wranling) that won't be published Personas for the flow chart for testing it - Dr researcher/postdoc/professor - Staff not research (e.g. Aalto ITS) - Master/Bachelor student who wants to do a thesis - Visitor that is not affiliated (fidepro etc) - Someone doing a project with industry with NDA, no publication (maybe not up to us to decide?) - Master student doing course work but with data on scratch Should the PI make a request for non affilated users? Maybe not, let's keep it like this, however it would be the transfer of responsibility. --- RD's flowchart: * have an aalto account? * LDAP shows ~~a research-focused title or a employee title~~ employee title that isn't "TA" → make account * let's pull a list of these "titles" * TA but also a researcher (as found through LAPA or something) → make account * does a research PI vouch for their use case → make account * else: → check their supervisor, if research PI says 'yes' → make account * else → ask Mikko --- ## how about the project folders? who to email to create what? Some research groups know, some do not. Maybe another flowchart.
Last changed by  
 
AaltoSciComp
120

Read more

Triton v3 communication

about 20% of current Triton resources (cpu, gpu, etc). Rest will be migrated shortly.

4/16/2024
FCCI Tech

Quick look at the code: Why should it be published separately?

1/26/2024
Linux Shell Scripting / January 2024 (live)

To watch: link will be sent to registered participants

1/18/2024
Kubernetes application demo

The goal of this lesson is to have a crash course of kubernetes, so that someone (who knows a bit about kubernetes already) can deploy a simple app to k8s cluster. We probably won’t say everything that someone needs, but hopefully you will know where to start reading to accomplish your need.

11/18/2023
Read more from AaltoSciComp
Published on HackMD