December 2009 - pgi-wg - lists.ogf.org

Actions from Meeting, 2009-12-04
by Johannes Watzl 07 Dec '09

07 Dec '09

action (Morris): session proposals -> call for sessions action (Morris): should arrange that someone from gLite is there action (Morris): check if there is a BES session, discuss with Andrew action (Aleksander): security aspects for credentials in data staging will be done by Aleksander action (Morris): copy strawman rendering doc (latest version from Aleksander) to drafts action (Morris, all): strengthen gLite participation -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room E 005, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl

1 0

Notes from Meeting, 2009-12-04
by Johannes Watzl 07 Dec '09

07 Dec '09

Dear all, please see below the Notes from the meeting on the last Friday. They are also available on GridForge. Best, Johannes Meeting on 2009-12-04, 16:00 (CET) Notes (1) Report from OGF27 BES Session with PGI inputs Morris & Johannes first plan was not to go to OGF27 -> decided to go to OGSA_BES session interesting session with about 10-12 people attending discussion of the "meet in the middle" approach JSDL people also at the session work closely together with JSDL JSDL instance schema much mor richer JSDL SLA people are driving it "on-top" thing on JSDL (keeping track etc.) first out of the focus of PGI basically discussions about Morris' slides from the NorduGrid conference session directory discussed long single- and multicore processiong Balazs: progress of strawman rendering doc is important! BES2.0, JSDL2.0 scondary point Morris: reference implementation keep in one doc to make progress resource sharing also discussed - different shares in one BES different ways how BES is deployxed in the different middlewares from certain perspective PGI is BES in some way now because PGI specificatiion will become BES specification overlap with PGI of about 90% It is very important to: go forward with PGI til the OGI 28 in Munich in March - before the new projects start!! (2) Plans for OGF28 in Munich: GIN Interop Day with PGI output Morris Interoperability day in Munich whole day GIN and PGI session with presentations and discussions reference implementation very likely in January -> show at OGF28 How to fill the day? 2 slots for GIN other time for PGI suggestions? general PGI presentation show reference implementation 2 GIN, 2 PGI + working sessions on other days action (Morris): session proposals -> call for sessions Balazs: three working sessions, half a day action (Morris): should arrange that someone from gLite is there Balazs: Will there be a BES session at the OGF28? Morris: if so we should align action (Morris): check if there is a BES session, discuss with Andrew (3) Reports about Lessons learned and further potential inputs of HPC-BP demonstrations David skipped (David not present) (4) PGI Tasks & Plans Reviews Morris & Johannes go through actions from 9 Oct 2009 action: security aspects for credentials in data staging will be done by Aleksander action (Morris): copy strawman rendering doc (latest version from Aleksander) to drafts Etienne: discussions about actions, already sent out - will resend it Balazs: discuss next meeting suggestion: switch track changes on accept changes in meeting Morris: screen sharing Balazs: just rendering doc is intersting for discussion high quality doc is important!!! Morris: put conclusions from discussion in the document Balazs: making progress on the doc is important!! Morris: Absence during Christmas? starting 18 Dec. 2nd week of January everybody is back (5) AOB next meeting date Tue, 8 Dec 2009 action (Morris, all): strengthen gLite participation -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room E 005, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl

1 0

OGF PGI - Job State Model - Execution Service Strawman
by Etienne URBAH 04 Dec '09

04 Dec '09

Balazs, Morris and all, Concerning the last OGF PGI telephone conference on 05 August 2009 : Meeting notes ------------- I see NO meeting notes about this telephone conference at http://forge.gridforum.org/sf/discussion/do/listTopics/projects.pgi-wg/disc… So I am working with my own (fragmentary) notes. For all future OGF PGI telephone conferences, is it possible that a secretary or a chair takes meeting notes, then writes them down in a understandable form, and publish them at the above mentioned page ? Creation of a 'Submitted:Hold' substate ? ----------------------------------------- First, as general rules, I consider that : - In order to AVOID keeping (potentially large) grid resources while NOT computing, grid Jobs should be designed to be processed completely automatically, with NO provision for 'Hold' substates, - A grid Job needing many 'Hold' substates can NOT be handled by an automatic Submitter, but should be submitted by a human grid User as an 'Interactive Job', as described for example at https://edms.cern.ch/file/722398//gLite-3-UserGuide.html#SECTION00084400000… Someone asked for the creation of a 'Hold' substate inside the 'Submitted' state, like inside other states. This 'Submitted:Hold' substate would make sense only if the Job Submitter could perform an operation on this substate. In order to request such an operation, the Job Submitter needs the Jobid (or Job EPR). This Jobid (or Job EPR) is guaranteed to be allocated by the Execution Service only at the END of the 'Submitted' state, but NOT before. Therefore, I consider that the 'Submitted' state can NOT contain a 'Hold' substate. If anyone thinks otherwise, can he/she please present a convincing Use Case ? Precisions about the 'Finished with Success or Error' state ----------------------------------------------------------- Someone asked that the 'Error' case of the 'Finished with Success or Error' state should be moved to the 'Failed' state. In fact, inside the current Job State Model, a Job reaches the 'Finished with Success or Error' state if and only if it successively reached the end of following states, without failure or cancellation at the JOB level : - 'Pre-processing' - 'Delegated', whatever the Application result : - Success = Application return code equal to zero - Error = Application return code different of zero - 'Post-processing' Inside the 'Finished with Success or Error' state : - Success means 'Application return code was equal to zero', - Error means 'Application return code was different of zero'. I copied this behavior from the Job State Model of 'gLite', where the 'Done' state contains both the 'Success' and 'Exit Code !=0' cases, as can be seen in the 'bookkeeping information' at https://edms.cern.ch/file/722398//gLite-3-UserGuide.html#SECTION00084100000… I consider this behavior design, and the strong separation between the 'Failed' and 'Finished with Success or Error' states, as fully justified by following reasons : - Whenever a Job reaches the 'Failed' state, the grid Execution Service detected an unrecoverable inconsistency at the JOB level. Therefore, the Job output sandbox and the post-processed Application output files can potentially be NOT consistent and NOT even accessible by the Job Submitter. In order to investigate the Job failure, the grid User then needs some grid knowledge (and often experience and expertise) to retrieve and interpret : - the Job failure code and message, - the Job logging and bookkeeping, in comparison with the Job description. This 'grid level' investigation can sometimes prove that the cause of the Job failure came from the Application, but is ALWAYS necessary. - Whenever a Job reaches the 'Finished with Success or Error' state, the grid Execution Service could create the Job output sandbox, and perform post-processing on Application output files, WITHOUT detecting any unrecoverable inconsistency at the JOB level. Therefore, the Job output sandbox, and the post-processed Application output files, can be supposed to be consistent and easily accessible by the Job Submitter. On a non-zero return code of the Application, the grid User : - first has to look (WITHOUT needing any grid knowledge) at the Job output sandbox and at the post-processed Application output files for an Application problem, - before, if necessary, using grid knowledge (and often experience and expertise) to provide any evidence that the Application error was caused by a faulty Job description, the Batch system, or the grid Execution Service. As a summary, I consider that the 'Error' case of the 'Finished with Success or Error' state should be kept as it is, and NOT be moved to the 'Failed' state. If anyone thinks otherwise, can he/she please present convincing reasons ? Strawman Rendering ------------------ I will work on the ODT version of 'Strawman Rendering' at http://forge.gridforum.org/sf/go/doc15628?nav=1 in order to : - include the above precisions on states, - include the 'Types of grid Jobs' section of my 'PGI Execution Service Overview' document, - check consistency, and present the relationships between the operations described in chapter 2 'Interface: Execution Port-Type' and the different states of the different types of grid Jobs. Joining +9900827049931906 (plus perhaps Skype typing) on Friday 14 August 2009 at 16h CET. Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------

2 4

[Fwd: Actions from 2009-10-09]
by Johannes Watzl 04 Dec '09

04 Dec '09

-------- Original-Nachricht -------- Betreff: [Pgi-wg] Actions from 2009-10-09 Datum: Fri, 09 Oct 2009 17:15:50 +0200 Von: Johannes Watzl <watzl(a)nm.ifi.lmu.de> An: pgi <Pgi-wg(a)ogf.org> Dear all, please see below the actions defined in the meeting today Best, Johannes - Action for Balazs and Morris: GLUE 2 tunings, exectution port type Action for Balazs and Morris: fault mechanism in the reference implementation epr - Action for Morris: security aspects for credentials in data staging - Action for Etienne: how much of the createActivity operation is covered by the state model? (client initiated data staging) - Action for Morris: createActivite figure of process should be delivered - Action for Morris: ask Shahbaz dataurl createActivity - Action to all: what is meant by service capabilities? link to GLUE2? influence? - Action for Etienne and Luigi: have a look at submit state email with answer email discussion will go on. - Action for Luigi: email: Subject createActivity operation, lease start email thread -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room D0.5, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl _______________________________________________ Pgi-wg mailing list Pgi-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room D0.5, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl

1 0

Notes of OGSA_BES session at OGF27
by Johannes Watzl 04 Dec '09

04 Dec '09

Dear all, please see below the notes from the BES session at the OGF27 in Banff. Best, Johannes Notes: Requirements Cream/ARC Steven: GLUE2: XML rendering not ready not talking about attributes Andrew: just relabelling Morris: in description of epr problem in GLUE2: circle dependecies an epr can have numerous resources and one resource can have numerous ep Andrew: in originalBES spec: no info Donal: retain info for how long? Andrew: til it is finished not make a minimum - imagine 10000 jobs -> huge amount of data you should not be able to see other people's eprs PGI requirements createActivity pending -> running stay there? was put out the original pending, running, failed list, delete, copy, write Morris: refine -> more detail in fault Philipp: lot of checking needed Steven: if element not supported -> throw fault now: bit more information Andreas: no endpoint in JSDL Andrew: enumerate classes of problems Morris: do we want them in the spec? Steven: session directory Andrew: what is session directory? Steven: URI is returned to client see from state machine -> kick off exec Andrew: rather profile Morris: never using service staging in Steve: avoid roundtrip David: no staging in just running? Andrew: doc that comes in not for JSDL -> activity doc that includes JSDL Philipp: activity ep doc Andres: BES ep profile Morris: when decide start/run/stop hold point spec. JSDL S0 -> S0' -> S1 stop here Andreas: data staging described outside Morris: should it be interface or JSDL issue? Andreas: complex workflow not good to put it in JSDL Andrew: stop:hold points Morris: also pre- and post processing - call preproc, put data right - job run - post proc Andrew: not putting complete workflows Andreas: not in JSDL -> specify Morris: working dir in JSDL but not working you don't know where job is running Dave: underlying implementation Andrew: want run workflow on node!? Morris: single one Andrew: solve problem: you need to come back to same container Morris: one BES; 4,5 nodes Andrew: local data management how people mount file system Steve's suggestion: BES container epr Philip:inUNICORE after job is done all dirs are cleaned more like an implementation issue session dir is no problem Steve: JSDL control: do it or don't do it finer control wanted Andrew: data motion is also a job determine, add requirements how are we going to handle these problems? look at different mechanisms have working dir, can persist potentially run jobs in session dirs -> data close external reference purge, create seperately give scratch space Morris: what if lots of CPUs needed later? Andrew: scheduling decision David: two stages Andrew: two function calls: slower Morris: epr must be refined Steve: do you have a simple BES ep? represent resource sharing in BES interface Andrew: BES has management interface Steve: Why does share of resources need to be reflected? Andrew: Behind the scenes we can have different BES for different queues. -> separate BES resource for each phys. queue Morris: In EGEE: one BES container somewhere David: queueing on VOMS attributes job manager does automatic queuing WMS does not include queue name in the job description Steven: Why not reflected job requirements in JSDL doc? Morris: maybe Andreas: feature where are you submitting to David: complete different ways in lsf and Condor Andrew: that's why different BES Steven: BES endpoint multiple resources Morris: JSDL: specify share keeping contacts only once Andrew: encapsulate or not? Steven: GLUE2: coordinates of info about resources -> GLUE2 service ep BES ep described through GLUE2 Morris: different containers Steven: different endpoints Donal: WS-addressing Morris: WSRF Andrew: WSRF and WS-addressing are not coupled Morris: reference parameters black box to users Andrew: two choices * let PGI dow what they need for the specification * BES 1.1 going to BES 1.1 coupled with JSDL Morris: slide "Refinement concepts overview" David: information service Steven: What to do with GLUE2? Steven: job info in GLUE2 scheme Andrew: we talk to endpoint to find out the requirements push or pull model? for dynamic meta data push model good notification system Andrew: HPC resource? not an OGSA-BES thing Steven: back to session dir Andrew: one execution line to multiple execution lines Andreas: it is a workflow Andrew: you can do this with BES: Data-Transfer delegation when BES service is running it does delegation Philip: activity instance schema keep history what happened to activity Andrew: send log info to some place Philip: use case from D-Grid Platform UNICORE Andrew: profile GLUE2 used for? Andrew: GLUE2 schema not an implementation Alexander: if you submit activity doc you get back an endpoitn Steve: will there be something from BES 1.0 in BES 1.1 Andrew: everything will change comepletely new namespace supporting both port types in the same service Steven: backward compatiblilty implementing the two different port types Andrew: 1.1: superset of 1.0 implement 1.1 machinery on 1.0 Steven: client with 1.0 should be able to use 1.1 next steps: - Group is revising - Strawman within BES - Work on the concepts one at a time - Not starting with delegation - Different implementations -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room D0.5, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl

1 0

Agenda & Reminder PGI Telcon on Friday 2009-12-04; 4 pm CET
by Morris Riedel 04 Dec '09

04 Dec '09

Hi PGI team, just a short reminder of the telcon we have this afternoon. So far, the agenda is as follows: (1) Report from OGF27 BES Session with PGI inputs Morris & Johannes (2) Plans for OGF28 in Munich: GIN Interop Day with PGI output Morris (3) Reports about Lessons learned and further potential inputs of HPC-BP demonstrations David (4) PGI Tasks & Plans Reviews Morris & Johannes (5) AOB Please let me know if you want to discuss any other items. I would aim to have a telcon for 1 hour, but looking on the agenda it might be wise to plan for 1,5 - 2 hour(s). Take care, Morris >------Original Message----- >-From: Morris Riedel [mailto:m.riedel@fz-juelich.de] >-Sent: Wednesday, December 02, 2009 10:42 AM >-To: 'pgi' >-Cc: 'gin(a)ogf.org' >-Subject: PGI Telcon on Friday 2009-12-04; 4 pm CET >- >-Hi team, >- >- after the long and exhaustive process of project proposal submission in Europe it's time to continue the PGI discussions to make >-progress on our specifications. >- >-To join the PGI teleconference on Friday, 2009-12-04 at 4 p.m. CET (UTC+1), please use this calling information: >- >-(1) >-Numbers >- >-via Skype call +9900827049931906 (free of charge), ordinary phone numbers >-(local rates) with the 9931906 conference number: >- >-Austria 0820 401 15470 >-Belgium 0703 57 134 >-France 0826 109 071 >-Germany +49 (0) 180 500 9527 >-Switzerland 0848 560 397 >- >- >-(2) >-Agenda >- >-The agenda will be rather simple basically checking all our open points and a "where-are-we" discussion in terms of tasks and future >-plans. >- >- >- >-A high participation from the PGI and GIN members would be appreciated. >- >-Your co-chair, >-Morris >- >------------------------------------------------------------- >-Morris Riedel >-SW - Engineer >-Distributed Systems and Grid Computing Division >-Jülich Supercomputing Centre (JSC) >-Forschungszentrum Juelich >-Wilhelm-Johnen-Str. 1 >-D - 52425 Juelich >-Germany >- >-Email: m.riedel(a)fz-juelich.de >-Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel >-Phone: +49 2461 61 - 3651 >-Fax: +49 2461 61 - 6656 >- >-Skype: MorrisRiedel >- >-"We work to better ourselves, and the rest of humanity" >- >-Sitz der Gesellschaft: Jülich >-Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 >-Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe >-Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), >-Dr. Ulrich Krafft (stellv. Vorsitzender) >-

1 0

Re: [Pgi-wg] PGI Telcon on Friday 2009-12-04; 4 pm CET
by Luigi Zangrando 03 Dec '09

03 Dec '09

Hi Morris, unfortunately tomorrow I cannot join the PGI teleconference, really sorry. take care, Luigi Morris Riedel wrote: > Hi team, > > after the long and exhaustive process of project proposal submission in Europe it's time to continue the PGI discussions to make > progress on our specifications. > > To join the PGI teleconference on Friday, 2009-12-04 at 4 p.m. CET (UTC+1), please use this calling information: > > (1) > Numbers > > via Skype call +9900827049931906 (free of charge), ordinary phone numbers > (local rates) with the 9931906 conference number: > > Austria 0820 401 15470 > Belgium 0703 57 134 > France 0826 109 071 > Germany +49 (0) 180 500 9527 > Switzerland 0848 560 397 > > > (2) > Agenda > > The agenda will be rather simple basically checking all our open points and a "where-are-we" discussion in terms of tasks and future > plans. > > > > A high participation from the PGI and GIN members would be appreciated. > > Your co-chair, > Morris > > ------------------------------------------------------------ > Morris Riedel > SW - Engineer > Distributed Systems and Grid Computing Division > Jülich Supercomputing Centre (JSC) > Forschungszentrum Juelich > Wilhelm-Johnen-Str. 1 > D - 52425 Juelich > Germany > > Email: m.riedel(a)fz-juelich.de > Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel > Phone: +49 2461 61 - 3651 > Fax: +49 2461 61 - 6656 > > Skype: MorrisRiedel > > "We work to better ourselves, and the rest of humanity" > > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe > Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender) > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg >

1 0

Re: [Pgi-wg] PGI Telcon on Friday 2009-12-04; 4 pm CET
by David Wallom 02 Dec '09

02 Dec '09

Hi Morris, Can I include the demo and its usage as requirements gathering for applications usage and PGI. David On 02/12/2009 09:42, "Morris Riedel" <m.riedel(a)fz-juelich.de> wrote: > Hi team, > > after the long and exhaustive process of project proposal submission in > Europe it's time to continue the PGI discussions to make > progress on our specifications. > > To join the PGI teleconference on Friday, 2009-12-04 at 4 p.m. CET (UTC+1), > please use this calling information: > > (1) > Numbers > > via Skype call +9900827049931906 (free of charge), ordinary phone numbers > (local rates) with the 9931906 conference number: > > Austria 0820 401 15470 > Belgium 0703 57 134 > France 0826 109 071 > Germany +49 (0) 180 500 9527 > Switzerland 0848 560 397 > > > (2) > Agenda > > The agenda will be rather simple basically checking all our open points and a > "where-are-we" discussion in terms of tasks and future > plans. > > > > A high participation from the PGI and GIN members would be appreciated. > > Your co-chair, > Morris > > ------------------------------------------------------------ > Morris Riedel > SW - Engineer > Distributed Systems and Grid Computing Division > Jülich Supercomputing Centre (JSC) > Forschungszentrum Juelich > Wilhelm-Johnen-Str. 1 > D - 52425 Juelich > Germany > > Email: m.riedel(a)fz-juelich.de > Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel > Phone: +49 2461 61 - 3651 > Fax: +49 2461 61 - 6656 > > Skype: MorrisRiedel > > "We work to better ourselves, and the rest of humanity" > > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe > Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender) > > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg -- =================================== Dr David Wallom Technical Manager Oxford e-Research Centre University of Oxford Rm 160, 7 Keble Road Oxford OX1 3QG +44(0)1865 610601 ===================================

2 1

PGI Telcon on Friday 2009-12-04; 4 pm CET
by Morris Riedel 02 Dec '09

02 Dec '09

Hi team, after the long and exhaustive process of project proposal submission in Europe it's time to continue the PGI discussions to make progress on our specifications. To join the PGI teleconference on Friday, 2009-12-04 at 4 p.m. CET (UTC+1), please use this calling information: (1) Numbers via Skype call +9900827049931906 (free of charge), ordinary phone numbers (local rates) with the 9931906 conference number: Austria 0820 401 15470 Belgium 0703 57 134 France 0826 109 071 Germany +49 (0) 180 500 9527 Switzerland 0848 560 397 (2) Agenda The agenda will be rather simple basically checking all our open points and a "where-are-we" discussion in terms of tasks and future plans. A high participation from the PGI and GIN members would be appreciated. Your co-chair, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel(a)fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)

1 0