[ccp4bb] Postdoctoral Training Fellowship at the Francis Crick Institute - Costa lab

[Alessandro Costa]

dear all,


a new postdoctoral position is available at the Francis Crick Institute in 
London.


Our group (Est. 2012) works on the mechanism of eukaryotic chromosome 
replication.


We are looking for an enthusiastic researcher interested in how molecular 
machines function.

The perfect candidate will have a background in Biochemistry and/or Structural 
Biology. Prior experience in cryo-EM would be an advantage and not a strict 
requirement.


Available resources at the Crick include:


  1.  access to cryo-EM instruments: 2 Krios, 1 Talos Arctica microscopes, all 
equipped with direct detectors; 2 Spirit microscopes for cryo-EM grid screening.
  2.  access to state-of-the-art Science Technology Platforms, including 
Fermentation, Mass Spectrometry, Peptide Synthesis, Structural Biology and 
Scientific Computing.
  3.  A fully equipped Biochemistry lab with generous core funding from the 
Crick.

Interested individuals are welcome to contact me directly for more information.

Best,
Alessandro

Here are a few links:

The job:

https://jobs.crick.ac.uk/pls/corehrrecruit//erq_jobspec_version_4.display_form?p_company=1_internal_external=E_display_in_irish=N_applicant_no=_recruitment_id=007004_process_type=_form_profile_detail=_display_apply_ind=Y_refresh_search=Y


The lab:

https://www.crick.ac.uk/research/a-z-researchers/researchers-a-c/alessandro-costa/


The Crick:

https://www.crick.ac.uk


Selected papers:


Abid Ali F, Douglas ME, Locke J, Pye VE, Nans A, Diffley JF, Costa A CRYO-EM 
STRUCTURE OF A LICENSED DNA REPLICATION ORIGIN. Nat Commun., 2017 Dec; 8, 2241

Abid Ali F^, Renault L^, Gannon J, Gahlon HL, Kotecha A, Zhou JC, Rueda D, 
Costa A. CRYO-EM STRUCTURES OF THE EUKARYOTIC REPLICATIVE HELICASE BOUND TO A 
TRANSLOCATION SUBSTRATE. Nat. commun., 2016 Feb 18;7:10708 (^equal 
contribution).

Ballandras-Colas A, Maskell DP, Serrao E, Locke J, Swuec P, Jónsson SR, Kotecha 
A, Cook NJ, Pye VE, Taylor IA, Andrésdóttir V, Engelman AN, Costa A*, 
Cherepanov P*. A SUPRAMOLECULAR ASSEMBLY MEDIATES LENTIVIRAL DNA INTEGRATION. 
Science. 2017 Jan 6;355(6320):93-95.

Maskell DP, Renault L, Serrao E, Lesbats P, Matadeen R, Hare S, Lindemann D, 
Engelman AN, Costa A*, Cherepanov, P* (2015) STRUCTURAL BASIS FOR RETROVIRAL 
INTEGRATION INTO NUCLEOSOMES. Nature 523, 366-369. (*Corresponding authors).

Simon AC, Zhou JC, Perera RL, van Deursen F, Evrin C, Ivanova ME, Kilkenny ML, 
Renault L, Kjaer S, Matak-Vinković D, Labib K, Costa A*, Pellegrini L*. A CTF4 
TRIMER COUPLES THE CMG HELICASE TO DNA PO­­­LYMERASE α IN THE EUKARYOTIC 
REPLISOME. Nature. 2014 Jun 12;510(7504):293-7. (*corresponding authors).

Swuec P, Renault L, Borg A, Shah F, Murphy VJ, van Twest S, Snijders AP, Deans 
AJ, Costa A. THE FA CORE COMPLEX CONTAINS A HOMO-DIMERIC CATALYTIC MODULE FOR 
THE SYMMETRIC MONO-UBIQUITINATION OF FANCI-FANCD2. Cell Rep. 2017 Jan 
17;18(3):611-623.

Zhou JC, Janska A, Goswami P, Renault L, Abid Ali F, Kotecha A, Diffley JF, 
Costa A. CMG-POL EPSILON DYNAMICS SUGGESTS A MECHANISM FOR THE ESTABLISHMENT OF 
LEADING-STRAND SYNTHESIS IN THE EUKARYOTIC REPLISOME.PNAS. 2017 Apr 3.




Alessandro Costa
The Francis Crick Institute
1 Midland Road
London NW1 1AT
United Kingdom
Tel: + 44 (0) 20 37961812
email:alessandro.co...@crick.ac.uk




The Francis Crick Institute Limited is a registered charity in England and 
Wales no. 1140062 and a company registered in England and Wales no. 06885462, 
with its registered office at 1 Midland Road London NW1 1AT

Re: [ccp4bb] Help with assigning density

[Prem Prakash]

Is that positive density lying at the symmetry axis ? please check,  if yes
then probably you have to model  the appropriate compound with appropriate
occupancy.

Best

Prem

On Fri, Jan 26, 2018 at 11:10 PM, Vivoli, Mirella 
wrote:

> Hi Tristan!
> Definitely PEG, in the so called horseshoe shape.
> Cheers,
> Mirella
>
> Get Outlook for Android 
>
> --
> *From:* CCP4 bulletin board  on behalf of Tristan
> Croll 
> *Sent:* Friday, January 26, 2018 6:09:01 PM
> *To:* CCP4BB@JISCMAIL.AC.UK
> *Subject:* Re: [ccp4bb] Help with assigning density
>
> Yes it can. See 5x49 (residue 603) for a wonderful example.
>
> On 2018-01-26 16:46, Michal Boniecki wrote:
> > I have positive density around lysine residue (image). This density is
> > found in all crystals, and only with this lysine. It is solvent
> > accessible but again not only this one is surface K residue. Can PEG
> > wrap around lysine like this? Maybe someone else have seen similar
> > density and knows what it might be?
> >
> > Thank You
>

Re: [ccp4bb] Help with assigning density

[Vivoli, Mirella]

Hi Tristan!
Definitely PEG, in the so called horseshoe shape.
Cheers,
Mirella

Get Outlook for Android


From: CCP4 bulletin board  on behalf of Tristan Croll 

Sent: Friday, January 26, 2018 6:09:01 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Help with assigning density

Yes it can. See 5x49 (residue 603) for a wonderful example.

On 2018-01-26 16:46, Michal Boniecki wrote:
> I have positive density around lysine residue (image). This density is
> found in all crystals, and only with this lysine. It is solvent
> accessible but again not only this one is surface K residue. Can PEG
> wrap around lysine like this? Maybe someone else have seen similar
> density and knows what it might be?
>
> Thank You

Re: [ccp4bb] Help with assigning density

[Tristan Croll]

Yes it can. See 5x49 (residue 603) for a wonderful example.

On 2018-01-26 16:46, Michal Boniecki wrote:

I have positive density around lysine residue (image). This density is
found in all crystals, and only with this lysine. It is solvent
accessible but again not only this one is surface K residue. Can PEG
wrap around lysine like this? Maybe someone else have seen similar
density and knows what it might be?

Thank You

[ccp4bb] Vacancy for a Science Technician in Protein Crystallography and Biophysical Analysis at JIC, Norwich, UK

[clare stevenson (JIC)]

Dear All,
I would like to draw your attention to an open position for a science 
technician supporting the protein crystallography and biophysical analysis 
facilities at the John Innes Centre in Norwich, UK.
Details about the position (deadline for application: 16 Feb 2018) can be found 
here:
https://www.jic.ac.uk/training-careers/vacancies/2018/01/science-technician-protein-crystallography-and-bio/

Informal enquiries about the position can be addressed to 
nbi.recruitm...@nbi.ac.uk  (quoting reference 1003404) or 
clare.steven...@jic.ac.uk

Best wishes,
Clare


Science Technician (Protein Crystallography and Biophysical Analysis Facilities)

Applications are invited for an enthusiastic and motivated individual to join 
the John Innes Centre as a Science Technician supporting our Protein 
Crystallography and Biophysical Analysis facilities.

Background:

The John Innes Centre is an independent, international centre of excellence in 
plant and microbial sciences.

The Protein X-ray Crystallography (PX) facility provides services and expertise 
for the determination of the three-dimensional structures of proteins of 
interest. The Biophysical Analysis (BA) facility provides services and 
expertise to study important biomolecular interactions using the techniques of 
Surface Plasmon Resonance and Isothermal Titration Calorimetry. Together these 
facilities provide deep insights into molecular interactions, gene regulation, 
enzyme mechanism, protein function and protein evolution.

The role:

We are seeking a science technician to support the work of the protein 
crystallography (PX) and biophysical analysis (BA) facilities. 70% of the time 
would be spent supporting the PX facility and 30% supporting the BA facility. 
The major responsibilities would include looking after specialist lab 
equipment, replenishing laboratory stocks, and liaising with users of the 
facilities to ensure that the service delivered is of excellent scientific 
quality.

The ideal candidate:

We are keen to employ an enthusiastic person with proven laboratory skills who 
is eager to work on a scientific facility providing excellent expertise and 
services to both internal and external users. Candidates should possess a BSc 
or equivalent in a biological subject, or possess significant relevant 
experience of working in a laboratory setting.

The candidate must to be able to work independently, have excellent 
organisational skills and good oral and written communication skills. The 
ability to act quickly to give advice or troubleshoot any issues is also very 
important. The ability to work occasional unsociable hours is also required.

Additional information:

Salary on appointment will be within the range £24,300 to £29,750 per annum 
depending on qualifications and experience.  This post is for an initial 
contract of three years.

We welcome applications from candidates seeking job-share, part-time or other 
flexible working arrangements.

For further information and details of how to apply, please visit our web site 
http://jobs.jic.ac.uk or contact the Human Resources team on 01603 450462 or 
nbi.recruitm...@nbi.ac.uk  quoting reference 1003404.

We are an equal opportunities employer, actively supporting inclusivity and 
diversity.  As a Disability Confident organisation, we guarantee to offer an 
interview to all disabled applicants who meet the essential criteria for this 
vacancy. The John Innes Centre is also proud to hold a Gold Award from Athena 
SWAN and is a member of Stonewall's Diversity Champions programme.

The closing date for applications will be 16th Feb

For informal inquires feel free to contact 
clare.steven...@jic.ac.uk


Dr Clare E.M. Stevenson
John Innes Centre
Norwich Research Park
Colney Lane
Norwich
NR4 7UH
Tel 01603 450734

Re: [ccp4bb] Modelling protein/protein interfaces

[Maria Jose Sanchez Barrena]

I have also heard about Frodock. The primary reference:

J. I. Garzon, J. R. Lopéz-Blanco, C. Pons, J. Kovacs, R. Abagyan, J. 
Fernandez-Recio, P. Chacón (2009) FRODOCK: a new approach for fast rotational 
protein-protein docking Bioinformatics, 25, 2544-2551 

If you go to the webpage (http://chaconlab.org/modeling/frodock) you will see 
that in 2016 there was another update/release.

You can use a server as well: http://frodock.chaconlab.org/

Good luck!

Maria




El 26/01/2018, a las 14:17, Tristan Croll  escribió:

> I've been quite impressed by ClusPro (https://cluspro.bu.edu) in the past. 
> Rather than pure rigid-body docking it makes some (pretty good) effort to 
> adjust interacting sidechains into reasonable arrangements. The advanced 
> options also allow you to specify attractions and repulsions between specific 
> residue pairs so you can apply any experimental knowledge you have.
> 
> On 2018-01-26 12:34, Thomas Krey wrote:
>> Dear colleagues,
>> Is there any appropriate tool for docking an interacting protein to a
>> relatively large protein-protein interface (>2500 A2). We are facing a
>> hetero-oligomer for which we approximately know the interfaces as well
>> as the structures of the individual protomers and would like to model
>> the hetero-oligomer. I have done some small molecule docking before,
>> but the size of the interface seem to be prohibitive for using the
>> same tools in the case of such a protein-protein interaction.
>> Any help or suggestion would be highly appreciated.
>> Best wishes
>> Thomas

Re: [ccp4bb] Modelling protein/protein interfaces

[Tristan Croll]

I've been quite impressed by ClusPro (https://cluspro.bu.edu) in the 
past. Rather than pure rigid-body docking it makes some (pretty good) 
effort to adjust interacting sidechains into reasonable arrangements. 
The advanced options also allow you to specify attractions and 
repulsions between specific residue pairs so you can apply any 
experimental knowledge you have.


On 2018-01-26 12:34, Thomas Krey wrote:

Dear colleagues,

Is there any appropriate tool for docking an interacting protein to a
relatively large protein-protein interface (>2500 A2). We are facing a
hetero-oligomer for which we approximately know the interfaces as well
as the structures of the individual protomers and would like to model
the hetero-oligomer. I have done some small molecule docking before,
but the size of the interface seem to be prohibitive for using the
same tools in the case of such a protein-protein interaction.

Any help or suggestion would be highly appreciated.

Best wishes

Thomas

Re: [ccp4bb] Issues with latest XDS (20171218)

[Kay Diederichs]

Dear Keitaro,

I have come to the exact same conclusions, and the next version of XDS will 
revert to the old refinement behavior. 

As a preview, I've uploaded a fixed Linux binary (not the whole package, just 
xds_par)  to 
ftp://turn5.biologie.uni-konstanz.de/pub/xds/xds_par.refi_cell_position_together.bz2
 .

Thanks - also to Oliver for reporting the problem!

Kay 

On Fri, 26 Jan 2018 16:56:30 +0900, Keitaro Yamashita 
 wrote:

>Dear Kay,
>
>I also tested this using a publicly available data of thaumatin
>https://zenodo.org/record/10271
>(resolution ~1.4 Å, wavelength= 0.97625 Å).
>The camera distance from header is 265.27 mm. I tested this original
>distance and some shifts (+1, +2, +4, ..., +32 mm) with different
>versions of XDS.
>
>As a result, IDXREF of the old version (170615) successfully refined
>camera distance to ~265.0 mm if shift was less than or equal to +16
>mm. The statistics in CORRECT.LP was as good as that without shift.
>
>If the camera distance was fixed in IDXREF, statistics was
>compromised, but the refinement in CORRECT worked well and recycling
>of GXPARM.XDS improved the data quality.
>
>However, the new version (170720 or later) changed camera distance
>very little. Even with +1 mm shift the statistics was deteriorated,
>and CORRECT (GXPARM.XDS) also didn't change the distance a lot, which
>means the recycling of optimized parameters do not help. The new
>version seems to stick to the given camera distance too much as
>pointed out by many people.
>
>I agree that camera distance in the header should be accurate.
>However, I also wish to revert to the former behavior of XDS that
>expires very soon.
>
>Actually in previous versions (170615 or former) fixing POSITION in
>REFINE(IDXREF) was recommended, but the recycling could give an
>accurate distance. The current version seems to virtually have no
>option to refine the distance.
>
>Best regards,
>Keitaro
>
>On 24 January 2018 at 05:16, Kay Diederichs
> wrote:
>> Dear Oliver,
>>
>> sorry for the trouble!
>> A default should be correct in the majority of situations, but it's 
>> impossible to have it work for _all_ situations. The XDS default for 
>> REFINE(IDXREF) was changed (i.e. POSITION was removed) to improve the 
>> indexing for weak and lousy data, _and_ because the distance values from the 
>> header are nowadays almost always accurate. For data with very high 
>> resolution such as yours, and significantly wrong distance, this means that 
>> at high resolution in particular this default will lead to worse data. 
>> generate_XDS.INP (in XDSwiki) and (I think) autoPROC and xia2 explicitly 
>> include POSITION in the REFINE(IDXREF), i.e. override the default. Where did 
>> you get XDS.INP from?
>> Some comments:
>> a) this is why I recommend, for data sets that may be important, to always 
>> do one cycle of optimization, i.e. after CORRECT, "mv GXPARM.XDS XPARM.XDS", 
>> change XDS.INP to have the correct high-resolution cutoff (cutting after the 
>> last shell which still has a "*" in the CC1/2 column), adjust the 
>> FRIEDEL'S_LAW= setting, and run JOB=INTEGRATE CORRECT. In your case this 
>> would make the refined distance available to INTEGRATE, and should result in 
>> very good data.
>> b) at which beamline did you collect the data? Such a high difference 
>> between refined distance and distance from header is unusual, and should be 
>> reported to (and fixed by) the beamline staff.
>> c) for this beamline at least, one should use REFINE(IDXREF)=CELL BEAM 
>> ORIENTATION AXIS POSITION . I understand that you tried this and it didn't 
>> work? Maybe there is something else wrong then, e.g. another line later in 
>> XDS.INP resetting REFINE(IDXREF) to something else.
>>
>> If you cannot find the reason why including POSITiON into REFINE(IDXREF) 
>> does not help, pls send me enough data to reproduce the problem.
>>
>> best wishes,
>>
>> Kay
>>
>> On Tue, 23 Jan 2018 14:31:09 +, "Weiergräber, Oliver H." 
>>  wrote:
>>
>>>Dear all,
>>>
>>>After upgrading XDS from build date 20170601 to 20171218, I am experiencing 
>>>severe degradation of apparent data quality reported by CORRECT for certain 
>>>data sets. Following first indications of issues with a slightly problematic 
>>>candidate, I went back to a previously very well-behaved test case with 
>>>diffraction extending beyond 1.1 A. Using the same input with both program 
>>>versions, statistics are not too different out to approx. 1.6 A, but become 
>>>more and more divergent in outer shells. These are the values for the 
>>>highest-resolution shell (1.10--1.16 A):
>>>
>>>20170601:  I/sigI = 1.80; Rmeas = 59.9 %; CC(1/2) = 82.0 %
>>>20171218:  I/sigI = 0.14; Rmeas = 506.4 %; CC(1/2) = 5.8 %
>>>
>>>The refined cell constants are unreasonably different as well. Obviously, 
>>>something is going awfully wrong here, presumably related to errors in 
>>>geometry parameters 

Re: [ccp4bb] Modelling protein/protein interfaces

[Chandra]

haddock may be an appropriate tool

https://haddock.science.uu.nl/



On 26/1/2018 8:34 PM, Thomas Krey wrote:


Dear colleagues,

Is there any appropriate tool for docking an interacting protein to a 
relatively large protein-protein interface (>2500 A2). We are facing a 
hetero-oligomer for which we approximately know the interfaces as well 
as the structures of the individual protomers and would like to model 
the hetero-oligomer. I have done some small molecule docking before, 
but the size of the interface seem to be prohibitive for using the 
same tools in the case of such a protein-protein interaction.


Any help or suggestion would be highly appreciated.

Best wishes

Thomas

[ccp4bb] Modelling protein/protein interfaces

[Thomas Krey]

Dear colleagues,

Is there any appropriate tool for docking an interacting protein to a 
relatively large protein-protein interface (>2500 A2). We are facing a 
hetero-oligomer for which we approximately know the interfaces as well as the 
structures of the individual protomers and would like to model the 
hetero-oligomer. I have done some small molecule docking before, but the size 
of the interface seem to be prohibitive for using the same tools in the case of 
such a protein-protein interaction.
Any help or suggestion would be highly appreciated.

Best wishes
Thomas

[ccp4bb] Post doctoral position in structure-based hit discovery for antibiotic targets (Bergen, Norway)

[Ruth Brenk]

Hi,

I have an open position in my group at the University of Bergen (Norway) 
for structure-based hit discovery for targets for antibiotics.


I am looking for somebody with experience in at least one of the 
following areas:


X-ray crystallography of macromolecules
Assay development using surface plasmon resonance (SPR) or biolayer 
interferometry (BLI)

Fragment screening

Additional experience in any of the following fields will be an advantage:

structure-based ligand design using computational methods
recombinant protein expression and purification
diffraction data collection at synchrotron beamlines

https://www.jobbnorge.no/en/available-jobs/job/147097/postdoctoral-fellow-3-years-in-structure-based-hit-discovery-for-antibiotics

You are welcome to contact me for more information but the application 
has to be send via jobbnorge.no.


Regards

Ruth

--
Prof. Dr. Ruth Brenk
University of Bergen
Department of Biomedicine

ruth.br...@uib.no
+47 55586070

Visitor adress:  Mail address:
Jonas Lies vei 91Postboks 7804
5020 Bergen  5020 Bergen
Norway   Norway

 




 

Re: [ccp4bb] Issues with latest XDS (20171218)

[Keitaro Yamashita]

Dear Kay,

I also tested this using a publicly available data of thaumatin
https://zenodo.org/record/10271
(resolution ~1.4 Å, wavelength= 0.97625 Å).
The camera distance from header is 265.27 mm. I tested this original
distance and some shifts (+1, +2, +4, ..., +32 mm) with different
versions of XDS.

As a result, IDXREF of the old version (170615) successfully refined
camera distance to ~265.0 mm if shift was less than or equal to +16
mm. The statistics in CORRECT.LP was as good as that without shift.

If the camera distance was fixed in IDXREF, statistics was
compromised, but the refinement in CORRECT worked well and recycling
of GXPARM.XDS improved the data quality.

However, the new version (170720 or later) changed camera distance
very little. Even with +1 mm shift the statistics was deteriorated,
and CORRECT (GXPARM.XDS) also didn't change the distance a lot, which
means the recycling of optimized parameters do not help. The new
version seems to stick to the given camera distance too much as
pointed out by many people.

I agree that camera distance in the header should be accurate.
However, I also wish to revert to the former behavior of XDS that
expires very soon.

Actually in previous versions (170615 or former) fixing POSITION in
REFINE(IDXREF) was recommended, but the recycling could give an
accurate distance. The current version seems to virtually have no
option to refine the distance.

Best regards,
Keitaro

On 24 January 2018 at 05:16, Kay Diederichs
 wrote:
> Dear Oliver,
>
> sorry for the trouble!
> A default should be correct in the majority of situations, but it's 
> impossible to have it work for _all_ situations. The XDS default for 
> REFINE(IDXREF) was changed (i.e. POSITION was removed) to improve the 
> indexing for weak and lousy data, _and_ because the distance values from the 
> header are nowadays almost always accurate. For data with very high 
> resolution such as yours, and significantly wrong distance, this means that 
> at high resolution in particular this default will lead to worse data. 
> generate_XDS.INP (in XDSwiki) and (I think) autoPROC and xia2 explicitly 
> include POSITION in the REFINE(IDXREF), i.e. override the default. Where did 
> you get XDS.INP from?
> Some comments:
> a) this is why I recommend, for data sets that may be important, to always do 
> one cycle of optimization, i.e. after CORRECT, "mv GXPARM.XDS XPARM.XDS", 
> change XDS.INP to have the correct high-resolution cutoff (cutting after the 
> last shell which still has a "*" in the CC1/2 column), adjust the 
> FRIEDEL'S_LAW= setting, and run JOB=INTEGRATE CORRECT. In your case this 
> would make the refined distance available to INTEGRATE, and should result in 
> very good data.
> b) at which beamline did you collect the data? Such a high difference between 
> refined distance and distance from header is unusual, and should be reported 
> to (and fixed by) the beamline staff.
> c) for this beamline at least, one should use REFINE(IDXREF)=CELL BEAM 
> ORIENTATION AXIS POSITION . I understand that you tried this and it didn't 
> work? Maybe there is something else wrong then, e.g. another line later in 
> XDS.INP resetting REFINE(IDXREF) to something else.
>
> If you cannot find the reason why including POSITiON into REFINE(IDXREF) does 
> not help, pls send me enough data to reproduce the problem.
>
> best wishes,
>
> Kay
>
> On Tue, 23 Jan 2018 14:31:09 +, "Weiergräber, Oliver H." 
>  wrote:
>
>>Dear all,
>>
>>After upgrading XDS from build date 20170601 to 20171218, I am experiencing 
>>severe degradation of apparent data quality reported by CORRECT for certain 
>>data sets. Following first indications of issues with a slightly problematic 
>>candidate, I went back to a previously very well-behaved test case with 
>>diffraction extending beyond 1.1 A. Using the same input with both program 
>>versions, statistics are not too different out to approx. 1.6 A, but become 
>>more and more divergent in outer shells. These are the values for the 
>>highest-resolution shell (1.10--1.16 A):
>>
>>20170601:  I/sigI = 1.80; Rmeas = 59.9 %; CC(1/2) = 82.0 %
>>20171218:  I/sigI = 0.14; Rmeas = 506.4 %; CC(1/2) = 5.8 %
>>
>>The refined cell constants are unreasonably different as well. Obviously, 
>>something is going awfully wrong here, presumably related to errors in 
>>geometry parameters (which are expected to become increasingly detrimental 
>>with decreasing dmin). As it turns out, geometry refinement behaves 
>>differently in the latest version of XDS: most notably, IDXREF no longer 
>>refines the detector distance by default. This is significant in this case, 
>>as in version 20170601 the distance would shift by as much as 1.3 mm, 
>>resulting in successful integration and scaling. Unfortunately, re-adding 
>>POSITION refinement into REFINE(IDXREF) does not help, and even having it in 
>>all refinement scopes (IDXREF, INTEGRATE,